[izpack-devel] Multi-Panel Panels

[Klaus Bartz]

Hi Hal,

Am 09.01.2006, 18:29 Uhr, schrieb Hal Vaughan <hal at thresholddigital.com>:

> On Monday 09 January 2006 11:41 am, Klaus Bartz wrote:
>> Hi Hal,
>>
>> Am 08.01.2006, 21:04 Uhr, schrieb Hal Vaughan  
>> <hal at thresholddigital.com>:
>> > I have an idea for a panel that would search for specified versions  
>> of an
>> > application and report if it is on a computer or not.  In my case,  
>> this
>> > would
>> > help because my application needs OpenOffice 2.x.  If it is on the
>> > computer,
>> > I need the path to it, if it isn't, I need to know where I can install
>> > it.
>> >
>> > This would require multiple steps:
>> >
>> > 1) Ask end user if app is present
>> > 2) Search (if needed) to see if it is present and create list of
>> > locations of
>> > different versions or instances
>>
>> Or look (on windows) into the registry. There are all regular installed
>> version registered. For Unix you can do an other way, may be search the
>> common dirs for applications.
>
> That's one way.  I haven't gotten into that much detail yet.  But are all
> programs installed with IzPack in the registry?

Most not because this feature is only available since 3.8.0 :-)
But for your problem I have looked into my registry and there are both
programms registered.

> I know I, not being a
> Windows person, tend to forget to include things like that.  I think it  
> would
> be possible, if you're using the registry enabled version, to check the
> registry and, if not found, do a directory search.
>
>> > 3a) If app is present, ask end user which instance or version to use
>>
>> Do not forget to implement a range mimik (like in JDKPathPanel), or is  
>> your
>> application able to use any version of OpenOffice ?.
>
> I was thinking of something close to that, but I've seen programs change  
> their
> version messages from one version to another (other than just updating  
> the
> version number).  It'd be more work, but more accurate, to specify a  
> command
> (and parameters) and a list of acceptable or unacceptable strings to  
> search
> for in the output.  For example:
>
> $ bigapp --version
> BigApp, (C) 2005 by Megalithic Corporation
> Version 2.1.9
>
> $bigapp --version
> Monolithic Corporation, a Megalithic subsidary
> BigApp 1.9.2
> (C) 2005
>
> Since we're dealing with all programs out there, this would allow the
> developer to specify strings to match all acceptable (and some non
> acceptable) verisons.  A little more work, but it provides much more in  
> terms
> of ability and accuracy.
>

I agree. Because this behavior of real programms I have implemented a  
version
scanner in JDKPathPanel (line 167ff).

>> > OR
>> > 3b) If app is not present, ask end user where it can be installed.
>> >
>> > I've noticed most panels are simple, like many installers.  This keeps
>> > things
>> > easy for the end user, allows for uncluttered panels (that are less
>> > confusing), and also takes into account that different languages and
>> > translations may require different amounts of space.
>> >
>> > To do what I want to do would require either a cluttered panel where  
>> the
>> > lower
>> > portions would change according to input on the upper sections or  
>> several
>> > different panels (some that would appear under some conditions, others
>> > under
>> > other conditions).
>> >
>> > Is here any problem with a "panel" that needs to have 3-4 panels in a
>> > row?  In
>> > the Panels section of the install.xml file it might look like this:
>> >
>> > <panel classname="ApplicationFinderPanel" stage="1"/>
>> > <panel classname="ApplicationFinderPanel" stage="2"/>
>> > <panel classname="ApplicationFinderPanel" stage="3"/>
>> > <panel classname="ApplicationFinderPanel" stage="4"/>
>>
>> You know the problem with additional attributes in the <panel> element  
>> of
>> install.xml. Why not use four different panels? May be one with the base
>> outfit and three or four only with the additional different layout.
>
> I'm thinking of that.  I'm still working out the overall idea.  It could  
> be 4
> panels, specified in order (AppFinder0Panel, AppFinder1Panel, etc) or  
> with
> different names, but if the order number is in the name, it helps senile
> people like me keep them in order.
>

Yes, if an order is required, numbers in the name are a good idea.

>> In IzPack there is only one panel which can exist in more than one  
>> stages,
>> the UserInputPanel.
>> Look into UserInputPanel. Would you write a secound one?
>> It is a little bit complex. What is better, four simple hard coded  
>> panels
>> or one
>> really complex panel for which the most questions on this mailing list
>> will be come.
>
> I prefer the simpler panels.  I experimentend, though, and found just  
> the code
> for multiple panels was not hard.  There are some custom panels I'm using
> that I need several times, and I found it easy to set that up.  But  
> UserInput
> is definitely a complex panel.  I have no desire to write anything that
> complex -- which is why I was thinking of doing this as a series of  
> panels.
>

I have accepted this rule of IzPack (a panel is like a singelton) long  
time ago.
What I do is to write a base or intermediaer class which is configurable  
and
the derived classes are most only configure the base class. That was the
primary idea of splitting TargetPanel into a base class (PathInputPanel)  
and
a really short derived TargetPanel. I think, I have ~ 6 panels derived  
 from it.
OK, JDKPathPanel is not so short...

We have in our server installation a customized JBoss installation. In my
JBossPathPanel I ask with a Dialog triggert in the  
JBossPathPanel.panelActivate()
the user whether he/she would install the customized JBoss or use an  
allready
installed JBoss. Dependant on the return value of the Dialog I configure  
the
JBossPathPanel whether it should handle a path for the new customized  
installation
or a allready existent product. Late configure of PathInputPanel is  
possible.

OK, I tend to resolve problems via inheritance. You can do it in your way,  
that's
one of the big benefit of IzPack I think.

Cheers

Klaus


> Hal
> _______________________________________________
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/izpack-devel
>
>
> __________ NOD32 1.1356 (20060108) Information __________
>
> Diese E-Mail wurde vom NOD32 Antivirus System geprüft
> http://www.nod32.com
>
>



-- 
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/