Re: Swingactions

On Mon, 30 Jun 2003 06:20 pm, Mauro Talevi wrote:
> I thought sandbox was more for less clearly defined or not actively
> developed comps.
> but if we opt to leave comps only for stable and released we can
> move it to sandbox.

I don't think it was ever defined. ATM I think it should basically be the set 
of components that are released and that have a supported API etc.

> > * metadata: the metadata that represents each action
>
> we could separate the action metadata in an ActionMetaData class,

preferrable.

> but AbstractAction and ActionAdapter do much of that.

But that binds it to runtime instances. You could not create multiple 
instances from metadata but would have to re-run the loading etc.

> But what I would resist is the temptation to make it too generic
> 'cause it would evolve into a real framework and not a component to
> manage swing actions.  In particular I would stick with swing actions
> (Action is in javax.swing package) and with swing components.
> If we see the use case for something more generic we should refactor
> later.  in particular I'm not sure this should become a web-based on SWT
> action toolkit.  There already are some out there of that sort and
> should we decide to, we'd have to change name too ;-)

True but I guess thats largely just a side-issue. Personally I just want a 
swing toolkit that reads xml files and no more ;) However by decomposing the 
system in the way that I specified makes it easier to develope by keeping all 
components loosly coupled. If we never use it to create a SWT/AWT framework 
then I would still recomend loose coupling just for the stability and ease of 
development concerns.

> Do you find so much easier to unit test code only because split in
> different packages.  

No - it is more breaking it into different concerns. For example lets assume 
the following classes in my design;

ActionMetaData (a single Action)
ActionGroupMetaData (a named group of ActionMetaData objects)
ActionSet (a set of ActionGroupMetaData/ActionMetaData objects)

They are all passive imutable data objects. The only unit testing I do is by 
passing in nulls to ctors and make sure they throw exceptions ;)

ActionSetReader

All you need to do is test whether the specified input xml creates expected 
output ActionSet.

ActionSetRuntime

This is the hardest to test and it tests loading of images, creation of swing 
Action objects and so forth. Even so it is fairly easy to determine what 
Swing Action object comes out of an ActionMetaData as long as you have set up 
classloader correctly.

JFactory

No idea on unit testing GUI stuff as I have never done it before ;) However I 
suspect it would be easier to just test it using Mock Runtime which is 
populated with known Swing Action objects.

> need to think more about it - but I'm not sure the added complexity
> necessarily adds to the benefits.

Have a look at the xmlpolicy/classman toolkits and see what you think of their 
designs before you make up your mind ;)

> apart from having different implementations of the configuration
> (which is already cared for) can you provide an example of how the
> new package layout would be beneficial?

I couldn't care less about package layout or new input formats ;) However I 
would like to see a *MetaData layer inbetween the runtime representations and 
the input configuration.

-- 
Cheers,

Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof."                   *
*              - John Kenneth Galbraith               *
*-----------------------------------------------------*



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01