[izpack-users] Reading Attributes from install.xml

[miraodb]

Hi guyz !

i just saw your posts... didn't read the whole thing in deep details but 
i'll help while klaus get some rest !
no problem.

Hal you know my contacts... we can work on it together if you want.

cheers,
fabrice
----- Original Message ----- 
From: "Hal Vaughan" <hal at thresholddigital.com>
To: <izpack-users at berlios.de>
Sent: Tuesday, January 10, 2006 12:06 AM
Subject: Re: [izpack-users] Reading Attributes from install.xml


> On Monday 09 January 2006 05:41 pm, Klaus Bartz wrote:
>> Hi Hal,
>>
>> Am 09.01.2006, 21:33 Uhr, schrieb Hal Vaughan <hal at thresholddigital.com>:
>> > On Monday 09 January 2006 02:09 pm, Klaus Bartz wrote:
>> >> Hi Hal,
>> >
>> > ...
>> >
>> >> 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 find only a few references to SpecHelper and I'm not clear if an
>> > instance of
>> > it exists where it can be easily retrieved by a panel (I can't find a
>> > way to
>> > access it yet, but I'm looking).
>> >
>> > Is SpecHelper constructed at the start already and is it easily
>> > available to a
>> > panel?
>> >
>> > If not, is it important this be in that class, or would another class
>> > specifically targeted at this work?
>>
>> I have implemented the class for the custom action stuff. It simple makes
>> the
>> job to simplify the loading and variable substitution. And some helper
>> methods there.
>
> I found those after I sent the e-mail.  Those would definitely help in the
> parsing.
>
>> It is used in the custom action stuff
>> and in some of my custom panels which are not part of the common IzPack.
>> An instance can be created with the default constructor (it is a private
>> member in SimpleInstallerListener). You can use it in the same manner as
>> it is used
>> in the custom action stuff (one of the hole difference is that the base
>> class do
>> not support it).
>
> That's a part I was a little confused about.  I thought you were saying it 
> was
> already instantiated somewhere as a standard procedure.
>
>> To use it first read the spec with e.g.
>> getSpecHelper().readSpec(SPEC_FILE_NAME, new
>> VariableSubstitutor(idata.getVariables()));
>> With this the spec will be loaded from the subdir res from the jar file
>> and the
>> IzPack variables will be replaced. This is a little bit difficult for
>> panels if you
>> need the spec for the layout; the layout should be created at 
>> construction
>> time,
>
> One big advantage to what you already have is that variable substitution. 
> I
> had not even considered that!
>
>> this is after language selection and before any IzPanel; at this time 
>> only
>> variables
>> which are written in install.xml are present (and the defaults of the
>> common
>> variables). Makes not big sense. If you need the spec at panelActivate()
>> you have
>> all variables declared before. Therefore it can make sense sometimes to
>> declare
>> two specs, may be SimplePanelsLayoutSpec.xml and SimplePanelsSpec.xml (or
>> so).
>
> I wasn't thinking of anything that complex (as in two files).
>
> It could also get confusing, trying to keep track of which variables are
> parsed when.  Maybe the file could just be run through a variable
> substitution 2 times, once on initial loading, and again before use, but I
> think most of the variables would be used in the layout, which is at the
> start.
>
> I also see that you have some good ideas about how to do this.  I may have
> missed something you said, but it seems like it would be a good idea to 
> load
> SpecHelper once (I think you said this) in a class so all panels can 
> access
> it.  That way it reads in the data only once.
>
> My idea, which would use more resources was originally to have a class 
> that
> would see which panel created it, read in the file, and keep only the data
> for the appropriate panel.  But that would mean each panel would create a
> different instance of the class, which would not be as efficient.  Your 
> idea
> is definitely better.
>
> Since you're not going to be typing for a while, I can create enough to do
> what I need for my classes and when you're back to coding again, we can
> integrate it and make sure it fits properly in SpecHelper.
>
> If someone has a way we can/should make an already instantiated 
> SpecHelper,
> with all the info from the file already in it, I could work with that.
>
> Hal
> _______________________________________________
> izpack-users mailing list
> izpack-users at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/izpack-users
>