[Instant-user] Re: Design and features

[Danno F. <sh...@ya...>]

> Danno,
> The current design seems to be a bit too tightly
> coupled to swing/awt with references in a number of
> the net.sf.inform classes. You know this is the
> classic case for the application of the bridge and
> factory method patterns. 


It's not the net.sf.instant.inform classes that are so bad, it's the 
references to the net.sf.instant.inform.swing references that we should 
worry about.  The classes in inform.* itself I designed to be generic 
and to merely hold information from the presentation layer, which is 
implemented in inform.console and inform.swing, so we would need an 
inform.swt.  If there is presentation specific classes in inform.* they 
should definatly be abstracted out.

What we need is some sort of a class to generically get the splash  and 
wizard screens and attach the to their respective models in inform.*. 
 Right now they are done in the task classes itself, and you right we 
should seperate it and place it inside inform as smething like a 
PresentationLayerFactory class.

The question this raises is how do we decide which presentation layer to 
trip?  I was initially using a magic property "inst.ant.console," if the 
awt classes failed to initialize or this property was set to true then I 
would do the console path.  We could stay with the magic property and 
change it to infom.ant.display and let ti take values of swing, swt, and 
console.  And we could add an attribte to InstSplash and Wizard to 
over-ride this (with console always being a back-up).


> Yes, I was asking specifically about what install
> related tasks you envisioned. Ant already supplies a
> great number of tasks that are useful during an
> install. However, some things I was thinking that are
> missing (and needed in during an install specifically
> in the Windows environment) are ways to interact with
> the registry and do things like add a shortcut to the
> desktop or a icon to the tooltray.
> 
> Ted



Those would go under net.sf.instant.propellant, and definatly need to be 
written at some point.  Single platform specific tasks would be ok, and 
I would think they should go under propellant.win, propellant.linux, 
propellant.macosx, etc.  Raw Registry interaction would go here.  If any 
of those tasks run on a platform that doesn't make sense for them the 
should quietly do nothing (perhaps logging that on the verbose level). 
 Tasks that do things that can have similar affect on multiple platforms 
can go jsut under propellant, such as adding desktop icons, application 
menu icons, and quick-start links.  These should deligate to classes 
inside of propellant.* based on the paltform ideally.  As for adding a 
tooltray icon, that seems to be a runtime dependent feature.

By the way, if you have a better ant pun than propellant for these 
features feel free to mention it, propellant seems close but not quite 
close enough to me.

--Danno