> Doc:
> Better documentation - sure go and write it - we will gladly insert it
> into the next distribution.
I have to understand it, first! And there are general architectural
decisions (like those mentioned below) that I may never know or fully grasp.
> ...
> Swixml is no quick and easy GUI builder. Developers deciding to
> use Swixml need to have a solid understanding of the underlying
> javax.swing objects and Widgets.
This is perfectly reasonable -- but that, too, should be documented.
;-) For example, it is implied, but not specified, that the XML
hierarchy corresponds to the component hierarchy.
> All this does not mean that we don't need documentation - but
> currently we are working on finalizing the 1.0 API rather then
> "getting started" guides. Anyone with some technical writing skills
> however is very welcome to jump in.
Perhaps after working with SwixML more I will have enough understanding
to do so. Do any rough outlines of such documents exist?
> Requirements:
> You don't have to overwrite SwingEngine, this was used to make the
> samples as compact as possible. Look at the Applet sample code, which
> doesn't overwrite SwingeEngine but uses composition instead.
Can this method be used with public Action objects? I'm guessing not.
> Providing public Actions member variables with anonymous inner classes
> implementations to handle events creates compact and readable code.
One minor nitpick: the public Action members do _not_ have to be
anonymous inner classes or anything... just member variables
implementing Action. I just want to mention this to prevent confusion.
One of the samples, Actions.java also has this in a comment:
//
// For every Actions, there needs to be a
// public AbstractAction member variables with an anonymous inner
// class instantiation
//
> However,
> you can also use ActionCommands to avoid having public Action fields.
I'm guessing you mean doing this with a single action listener, and the
SwingEngine.setActionListener() method?
> The idea with the action map was actually discussed but dismissed for
> the 1.0 release. However, we are going to re-visit this issue after
> 1.0 is finalized.
Even something as simple as being able to pass a proxy object in would
be fine. That proxy could be 'this', which is how things work today.
But it would be nice to be able to seperate the actions out.
For example:
public Container render( final URL url) throws Exception {
render(url, this);
}
public Container render( final URL url, Object actionsProxy )
throws Exception
{
// does pretty much what render(URL) does now...
// note that the actions proxy would have to be passed to the
// Parser instance...
}
Probably a preferable way would be to have an ActionsMap interface with
a single method, getAction(String name). SwingEngine could implement
that method through reflection in a similar manner to the current operation.
> We experimented with all kinds of ways to do event handling. the
> public Actions won since the code is compact and more inline what
> swing developers are already used to.
You may be right on this. I don't want to reduce functionality, just
make it more flexable.
> LayoutManager:
> It's not to hard to add support for new LayoutManagers. Again, if you
> do write converters that you want to share. Let us know and we are
> going to add them to the builds.
Well, a simple layout is always a dream; in reality it is very complex.
BorderLayout SwixML documents look very nice, but GBL docs are ugly.
But this is probably a necessary evil.
Pat.
