[izpack-users] Reading Attributes from install.xml

[Hal Vaughan]

On Monday 09 January 2006 06:17 pm, Klaus Bartz wrote:
...
> >
> > 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/>
>
> No, that you cannot write in a dtd.
> The name of the panel is not an element else an attribute of the element
> which handles panels.
> No text in a spec file else a key into the locale file.
> It will be better if variable names has a "namespace".
> What about pack dependance?
> <simplespecs>
> 	<simplepanel name="simplestuff1panel">
> 		<panel txtkey="simplestuff1panel.panel0.txt"
> variableName="simplestuff1panel.bgcolor">
> 	     <panel order="1" txtkey="simplestuff1panel.panel1.txt"
> variableName="simplestuff1panel.fgcolor">
> 		<panel order="2" txtkey="simplestuff1panel.panel1.txt"
> variableName="simplestuff1panel.fontcolor"> 	<simplepanel/> 	<simplepanel
> name="simplestuff2panel">
>   	<simplepanel/>
> <simplespecs/>

Okay.  I see.  Thanks for correcting that!

> > 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.
>
> Generell an interesting point. Little problems if the text of the
> panel should also depence on the order.

It would be up to the developer to keep the right resource associated with the 
right panel, maybe numbers in the names would help:

	<simplepanel name="multiinfopanel>
		<panel order="0" resource="info0text.xml"/>
		<panel order="1" resource="info1text.xml"/>
	<simplepanel name="multiinfopanel/>

That way, when the panel asked for a property, it would have to specify its 
instance number.  The method could be overloaded so if no instance number is 
specified, a default of 0 is used and the full method is called with that.

> >> 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
>
> But without throw if not exist or at the first call of getCommonPanelsSpec.
> May be an installation will not use panels which using this and we will be
> compatible to older configurations. All new features has to be facultative.

Certainly.  I am thinking of adding functionality, but not doing something 
that breaks what is there.  So this entire thing could be ignored by panels 
that don't use or need it -- as if it were never there.  I didn't want to 
force changes.  That's one reason I was thinking of "MultiInfoPanel", it 
would be very close to InfoPanel, but would allow multiple uses of the same 
panel.  InfoPanel and other existing panels would not change at all.  Only 
newer panels that want to use this spec file would use it.

Hal