[izpack-devel] Multi-Panel Panels
bartzkau at gmx.net
Mon Jan 9 20:30:38 CET 2006
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,
>> > 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
> I know I, not being a
> Windows person, tend to forget to include things like that. I think it
> 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
>> application able to use any version of OpenOffice ?.
> I was thinking of something close to that, but I've seen programs change
> version messages from one version to another (other than just updating
> version number). It'd be more work, but more accurate, to specify a
> (and parameters) and a list of acceptable or unacceptable strings to
> 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
> of ability and accuracy.
I agree. Because this behavior of real programms I have implemented a
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
>> > lower
>> > portions would change according to input on the upper sections or
>> > 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
>> 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
> 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
>> the UserInputPanel.
>> Look into UserInputPanel. Would you write a secound one?
>> It is a little bit complex. What is better, four simple hard coded
>> 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
> 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
I have accepted this rule of IzPack (a panel is like a singelton) long
What I do is to write a base or intermediaer class which is configurable
the derived classes are most only configure the base class. That was the
primary idea of splitting TargetPanel into a base class (PathInputPanel)
a really short derived TargetPanel. I think, I have ~ 6 panels derived
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
the user whether he/she would install the customized JBoss or use an
installed JBoss. Dependant on the return value of the Dialog I configure
JBossPathPanel whether it should handle a path for the new customized
or a allready existent product. Late configure of PathInputPanel is
OK, I tend to resolve problems via inheritance. You can do it in your way,
one of the big benefit of IzPack I think.
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> __________ NOD32 1.1356 (20060108) Information __________
> Diese E-Mail wurde vom NOD32 Antivirus System geprüft
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
More information about the izpack-devel