[izpack-users] Reading Attributes from install.xml

[Hal Vaughan]

On Monday 09 January 2006 11:30 am, Klaus Bartz wrote:
> Hi Hal,
> seems so you have started playing with IzPack. Nice tool, isn't it?

I'm having fun with 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.

How about a resource called panel.xml or panelconfigspec.xml that would 
contain attributes for several panels?  The reason I am bringing this up is 
I'm working on several panels that need something like 2-4 config options, 
and it is a bit frustrating to have a lot of files that have only 2-3 or so 
config options.

> 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.

Would there be a problem with creating an extra xml file that SOME panels 
could use for customization?  That way panels that only need a few attributes 
set don't need separate files for each panel.  Maybe the file could be names 
SimplePanelsSpec.xml to emphasize it is ONLY used by panels that have simple 
configurations and NOT by panels that are more complex.  I'd even be willing 
to write it up in the docs that way and list the panels that use it.

> > 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.

My thought on it, and my focus is for panels that only need a few simple 
config options.  Do you feel it would be possible to have one combined file 
for those panels, or better to have a lot of separate files of 2-3 lines 
each?

Hal