[izpack-users] How does variable substitution work?

[Bartz, Klaus]

Hi Gernot,
see context related.

Cheers 

Klaus

> -----Original Message-----
> From: izpack-users-bounces at lists.berlios.de 
> [mailto:izpack-users-bounces at lists.berlios.de] On Behalf Of 
> Gernot Stenz
> Sent: Thursday, June 14, 2007 10:45 AM
> To: izpack-users at lists.berlios.de
> Subject: Re: [izpack-users] How does variable substitution work?
> 
> 
> "Bartz, Klaus" <Klaus.Bartz at coi.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/soffice.exe"/>
> > in your parsable file
> > <value>${APPLICATIONS_DEFAULT_ROOT}${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:stenzg at informatik.tu-muenchen.de        /\
>    -\<,          WWW:  http://www4.in.tum.de/~stenzg          
>      /\/--\
> _(_)/(_)_London - Paris: 3547 
> km__________________________________/      \
> _______________________________________________
> izpack-users mailing list
> izpack-users at lists.berlios.de 
> https://lists.berlios.de/mailman/listinfo/izpack-users
>