[izpack-users] Reading Attributes from install.xml

[Hal Vaughan]

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