[izpack-users] Reading Attributes from install.xml

[Hal Vaughan]

On Monday 09 January 2006 02:09 pm, Klaus Bartz wrote:
> 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.

I understand.  Please don't think I'm complaining.  I'm trying to understand 
how to implement my ideas within the current IzPack framework.  That way they 
benefit you and everyone else and not just me.  I have no problem with being 
told that isn't the way it is done and given information on why or shown how 
to do it better or in a way that is more fitting.

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

I don't know how to express it technically, so here's an example of 
SimplePanelsSpec.xml:

<simplespecs>
	<simplestuff1panel>
		<panel txt="Select a background color" variableName="bgcolor">
		<panel order="1" txt="Select a foreground color" variableName="fgcolor">
		<panel order="2" txt="Select a font color" variableName="fontcolor">
	<simplestuff1panel/>
	<simplestuff2panel>
		<panel txt="Select mirror site for updates" variableName="updMirrir">
		<panel order="1" txt="Pick a download protocol" variableName="dlproto">
		<panel order="2" txt="How often should we update?" variableName="updfreq">
	<simplestuff2panel/>
<simplespecs/>

The <panel> elements would NOT have children.  (If they did, they would not be 
simple.  You may notice this also allows the same panel to be used multiple 
times.  I looked at UserInput and found all that was needed for multiple 
instances of a panel was 2 integers, a static one that keeps count of the 
number of instances of a panel and a protected one that is the instance 
number.  (Note that if no order attribute is given, it defaults to 0, for the 
first or only instance of that panel.)

A side note: I've noticed some comments about how it would be nice to have 
multiple InfoPanels or HTMLInfoPanels.  This would make it a snap with 
something like this added to SimplePanelsSpec.xml for a panel named 
MultiInfoPanel:

	<multiinfopanel>
		<panel order="0" resource="generalInfo.xml"/>
		<panel order="1" resource="upgradeInfo.xml"/>
	<multiinfopanel/>

I don't know if there is any reluctance to use multiple instances of panels, 
but I think this would provide an easy way for a simple panel to be used as 
many times as 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.

If you use that with my idea and the file format I just specified, then 
SpecHelper could load SimplePanelsSpec.xml at the start, and whenever it is 
called from a panel, it can determine the panel name automatically, so all it 
would need as a parameter is the instance number and it could return a 
Properties object with all the properties (or just the instance number and 
Attribute name and it would return the attribute value for that instance of 
the panel -- this method would be overloaded to not need an instance number 
and default to the first or only instance).

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

Is OP operation?  If so, good luck!

I don't mind doing it.  I have to parse some XML for my panels, and I might as 
well do the routines only once, in another class, than doing them over and 
over.  I just don't want to start hacking things in IzPack, come up with a 
huge and, to me, amazing idea, and find out it messes up other plans or 
ideas.

Hal