Re: How does variable substitution work?

Hi Gernot,
see context related.

Cheers 

Klaus

> -----Original Message-----
> From: izpack-users-bounceslists.berlios.de 
> [mailto:izpack-users-bounceslists.berlios.de] On Behalf
Of 
> Gernot Stenz
> Sent: Thursday, June 14, 2007 10:45 AM
> To: izpack-userslists.berlios.de
> Subject: Re: [izpack-users] How does variable
substitution work?
> 
> 
> "Bartz, Klaus" <Klaus.Bartzcoi.de> writes:
> 
> > Hi Gernot,
> 
> Good morning!
> 
> > variables will be not substituted by the contents
of 
> variables. I see 
> > to ways to solve your problem.
> > 
> > 1: write a custom action which does the
substitution.
> > 
> > 2: use
> > in install.xml
> > ...
> > <variable
name="APPLICATIONS_SUB_PATH" 
> >     
> >
value="/OpenOffice/orgPortable/App/openoffice/program/s
office.exe"/>
> > in your parsable file
> >
<value>$${APPLICATIONS_SUB_
PATH}</value>
> 
> Thank you! I hadn't thought of that! BTW, why the
braces 
> here? Are they necessary?

At this point they are not necessary but they do not
disturb. If you
ever had thought why a variable will be not replaced and
after some
times you have learned that variables with special cases
(e.g. a dot)
needs braces, you never write a variable without braces 

> 
> Also, on my way to the office this morning I thought of

> something different that turned out to be working:
> 
> I simply doubled the line containing the
<parsable> tag. My 
> installer xml now looks like this: ... <parsable
type="xml" 
>
targetfile="$INSTALL_PATH/Projektassistent-1.2.4rc3/res
/vmodel
> lexport.xml"/>
> <parsable type="xml" 
>
targetfile="$INSTALL_PATH/Projektassistent-1.2.4rc3/res
/vmodel
> lexport.xml"/>
> ...
> 
> And this procuded the desired result. Obviously the 
> <parsable> tag does not only mark a file as
parsable, every 
> tag seems to initiate a parsing run, and for a two
level 
> variable substitution problem, two tags apparently do
the trick.
> 

Yes, <parsable> do not mark a file for parsing else it
is really
a <doparse>. Therefore in this special case a doubled
call will work
for you. But is it not to much overhead compared with the
usage of
two variables? You create a new file, removes the old one
and rename
the new, you know...

> But now that I have more than one solution for the
problem, I 
> ask myself: Which is the canonical one more in line
iwth 
> IzPack's future development?
> 

I prefer the usage of more than one variable to supress a
recursive
design. If you think generic, you do not really know which
variable
depends on which and the secound on which third and so on.
Possible
to resolve, but not a thirty second job. Prevent circular
dependencies
and so on.
If I need a variable which I can only determine at runtime
(why ever),
I set it from a custom panel (may be where I have called the
user for
the contents of the variable) or write a custom action
(beforePack) 
which creates the variable. More than one time done.

> Ciao, Gernot
> 
> -- 
>     __o  Gernot Stenz  
> e-mail:stenzginformatik.tu-muenchen.de        /
>    -<,          WWW:  http://www4.in.tum.de/~
stenzg          
>      //--
> _(_)/(_)_bond - Paris: 3547 
> km__________________________________/      
> _______________________________________________
> izpack-users mailing list
> izpack-userslists.berlios.de 
> https://lists.berlios.de/mailman/listinfo/izpack-users

> 
_______________________________________________
izpack-users mailing list
izpack-userslists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-users