[izpack-users] Reading Attributes from install.xml

Klaus Bartz bartzkau at gmx.net
Mon Jan 9 20:09:43 CET 2006


Hi Hal,
it is often a play between make it "as simple as possible" and
as free as possible". I agree, that a separate file with dtd and docu
and so on is a little bit oversized for two or three lines.
But I am really not "assumed" about the config files
without a dtd because it is more difficult to validate. Many calls on
this list are related to bad written config files. I will nag if IzPack
gets a new spec file without a dtd.
Therefore a SimplePanelsSpec.xml ( or CommonPanelsSpec.xml ??) should
have a dtd. But in what manner we can define the syntax in a common way
useable from different panels where we do not know what they are needed.
In the moment I think with key value pairs. Uups, we have key value pairs
allready with element <variable> of installation.dtd.
Is it the right way to use an IzPack variable for configure a panel?
Good question, I do it in JDKPathPanel with the range values (line 66f).
Therefore I prefer to use an IzPack variable if only one or three values
are needed.

But if you would, why not a SimplePanelsSpec.xml. If so, I prefer if
there will be a (static ?) method in SpecHelper like
XMLElement getCommonPanelsSpec()
which loads once the spec and returns every call the root of the spec.
Or - if elements are fixed -
String getCommonPanelsValue(String panelName, String valueKey)
One point for a generic solution is the docu. It is not relevant
whether we love it or not (I hate it) but it has do be written.

I can do for it nothing next time because tomorrow is the last day I can
write during the next six or ten weeks (at 12.01.06 I have an OP at
my right wrist).

Cheers

Klaus

Am 09.01.2006, 18:20 Uhr, schrieb Hal Vaughan <hal at thresholddigital.com>:

> 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
> _______________________________________________
> izpack-users mailing list
> izpack-users at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/izpack-users
>
>



More information about the izpack-users mailing list