[izpack-users] Reading Attributes from install.xml

Klaus Bartz bartzkau at gmx.net
Tue Jan 10 00:17:01 CET 2006

Am 09.01.2006, 21:23 Uhr, schrieb Hal Vaughan <hal at thresholddigital.com>:

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

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?
	<simplepanel name="simplestuff1panel">
		<panel txtkey="simplestuff1panel.panel0.txt"  
	     <panel order="1" txtkey="simplestuff1panel.panel1.txt"  
		<panel order="2" txtkey="simplestuff1panel.panel1.txt"  
variableName="simplestuff1panel.fontcolor"> 	<simplepanel/> 	<simplepanel  

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

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

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

No it is time for me to go to bed...



More information about the izpack-users mailing list