[izpack-users] Reading Attributes from install.xml

Klaus Bartz bartzkau at gmx.net
Mon Jan 9 17:30:16 CET 2006


Hi Hal,
seems so you have started playing with IzPack. Nice tool, isn't it?


Am 09.01.2006, 07:57 Uhr, schrieb Hal Vaughan <hal at thresholddigital.com>:

> Remember I mentioned writing a class to read attributes given to panels  
> in
> install.xml?
>
> It's done.  It requires there to be a file /res/install.xml, which means  
> it
> has to be declared as a resource in the original install.xml file  
> (whatever
> it is named).  It could easily be changed to read from any XML file  
> anywhere
> in the install jar.

You have seen, that you cannot read install.xml because this file will be
not present at install time else only at packaging (compiling).
install.xml self is not a good place to add data for custom panels because
all people has to handle it and the dtd is large enough  
(src/dtd/installation.dtd)
and the file was not made to exist in the installation else only at  
packaging time.

Also other panels or custom actions uses an own xml file. It is common to  
give them a
name which has an association to the used class which use it; see
shortcutSpec.xml or RegistrySpec.xml. I think it will be an good idea to
write a dtd for it like src/dtd/event/registry.dtd for RegistrySpec.xml.
Problems with IzPack are often related with wrong written xml files. If we
change from the current xml parser (nanoxml) to one of the VM. Then
we would validate the xml files. I know, not all xml files (like the one
for the UserInputPanel) has a corresponding dtd, this is not good.

>
> I also edited PasswordPanel to get the panel attributes from this class
> instead of reading install.xml directly.
>
> It's time for sleep, but I thought I'd mention I had this working.  I  
> can send
> you the class once I've had time to clean up the code (way to many  
> debugging
> comments and printouts in there now!).
>
> I think I read somewhere that there was an intent to not let install.xml  
> get
> too cluttered.  Unless I missed a method somewhere (and I looked  
> carefully),

Yes, install.xml defines the hole installation, not additional data for a
custom panel or custom action (if we use the way for panels, the next  
question
will be why not for custom actions). Look into src/dtd/event/antaction.dtd.
How to put all the attributes and elements into the <listener> element of
install.xml

> the class I wrote (PanelAttributes) is the only allowance for reading the
> panel attributes.  If more panels are going to use this method of having
> attributes in the install.xml file, it seems to me it might be a good  
> idea if
> either the install.xml file is automatically included OR just the  
> <panels>
> section could be extracted and put in /res.
>

There are panels which needs a spec file, most not. It will be good if a  
spec
has a dtd. Therefore we need for each spec one file. I have had until jet
no problems to add the one or five  resource line(s) in install.xml for my
spec files.
There exist a helper class for specs, see  
com.izforge.izpack.util.SpecHelper.
Primary made for custom actions, but also useable from custom panels.

> Just some late night musings.  Let me know what you think and what I've  
> missed
> on this.
>
> Keep well,
>
> Hal
> _______________________________________________
> izpack-users mailing list
> izpack-users at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/izpack-users
>

Cheers

Klaus



More information about the izpack-users mailing list