Re: Swingactions

Peter Donald wrote:

> 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.

fine by me - don't really mind where it is developed.
I'll move it to sandbox then.

>>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.

true, and that becomes quite relevant when dealing with multiple 
components.  single component habits are hard to break ;-)

> 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.

yep - I'm an advocate of loose couplings :-)
but let's remain focused on the scope of the component.

> 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.
> 

actually, one thing I still had not made up my mind was whether to use a 
metamodel to group actions or simply Collection classes in the 
configuration.  but given the runtime decoupling argument I'm happy to 
adopt a metamodel.

> 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.

the nice thing about the Action/Command pattern is that it doesn't 
really matter where it is triggered.  so if the action is well tested 
then it becomes much less dependent on the widget that triggered it.
a simple approach that should suffice is to contruct a mock object
extending AbtractButton which (I think but need to check) is the base
class for all action-related JComponents (JButton and peers, JMenuItem 
etc...) and use fireActionPerformed() to trigger the action.
Else we can look into some gui testing framework that plugs into junit ...

> 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.

agreed.
As far as packages go, how about:
- root component package (ie org.jcomponent.swingactions) is the runtime 
representation including JFactory until there is a need for a separation.
- swingactions.metadata - the metamodel
- swingactions.reader - the input readers (which may or may not be 
subpackaged on the input type)


Cheers




-------------------------------------------------------
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