[izpack-devel] Multi-Panel Panels

[Klaus Bartz]

Am 09.01.2006, 20:59 Uhr, schrieb Hal Vaughan <hal at thresholddigital.com>:

> On Monday 09 January 2006 02:30 pm, Klaus Bartz wrote:
>
> ...
>> >> 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'm also using RealVNC, and haven't checked yet.  It's one of those  
> things
> Windows developers would be much more aware of than others.  I may write  
> the
> code for the directory search (I think there's one in UserInput that I  
> can
> copy) and let a Windows person write the registry code, if someone would
> like.  That's a ways off.  The first step is to get it working!  ;-)   
> Then
> it's time to figure out things like that.
>
> ...
>> > 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).
>
> I'll have to look at that.  I think I remember having that problem at one
> point a few years back when I had to figure out what version of Java a  
> system
> was using.
>
> ...
>> > 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...
>
> I've looked at those panels in passing.  I am not sure yet, but I think  
> I can
> use PathInputPanel as part of what I'm doing.  It's easier to figure out  
> what
> 3 panels of 200-400 lines are doing, if each handles separate tasks, then
> trying to read 600-1200 lines of code.  (And, the part I like is that  
> it's
> easier to debug!)
>

If the tasks are separated... I tend to make a bigger base class and then
as default inheritance implementation a thin as possible one (with javadoc
TargetPanel has 133 lines and there are many bla bla).
OK, one problem is, that there is no documentation outside the javadoc.
But at the point of implementing java classes I think the source is the
best docu :-)

>> 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.
>
> I think I'd use inheritance more if I understood it or was more used to  
> it.
> I'm self taught, especially in Java, and I learned what I have needed to
> write the programs I needed.  I'm learning more about using inheritance  
> in
> IzPack than I've learned before (and some of that is through the path  
> panels

IzPack is not so high in inheritance. At the early time there was no  
inheritance
of panels, it comes later.
  There are other things I have never thought that they are possible before
I have known IzPack. My big learning was the handling of native code and
the packaging of the dll/shl into the jar file. How means, it is not  
possible
to access the system with a java program loaded from a jar file has never
really looked into IzPack. OK, nothing todo with our current theme.

> you wrote and mentioned here -- so thanks!)
>

Inhertance cannot help at all. But one point is "if you implement one thing
at to points one of this points is to much". That's one of the things I  
have
learnd in the last fifteen years. Often some one (I) forget to make a  
bugfix also
at the second instance of the code. Therefore a code only at one point if
possible. For this inheritance can help (also possible at a function  
orientated
programming style).

> Hal
> _______________________________________________
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/izpack-devel
>
>