SwiXML robustitude (fwd)

Hello

While evaluating SwixML I had most of these questions too. FWIW, here's my take
on some of them.

Stability: I don't think you need worry about 2.0 breaking 1.0 XML. I'm
guessing we'll see added layouts though, and perhaps more ways to extend
without hacking code (ie a formalism of what I'm sure other people are already
doing to add basic glue of the type you mention). But I'm perfectly new to
Swix, so I'll shut up on this topic right now.

Scripting: you're right, some of the code falls between presentation and app
logic. I guess one way of identifying it is to say it's 'trivial presentation
logic' (eg if this box is checked, uncheck the others). Menu and button groups
seem to be handled explicitly in the XML parsing though.

Jelly Swing and Luxor-XUL both have scripting built-in, but it seems to add
significantly to the complexity, otoh their scripting is pretty complete.

Swix's small source is small and hackable in comparison, this is a big reason
why our project chose it.

I've spent a week trying to understand the Swix internals, and it looks pretty
flexible to accomodate stuff like glue code.  For instance, I could define a
custom tag, and as the text for that tag, write some pseudo-code like 'connect
A to B' or 'A.foo(B.bar)' and use the SwingEngine (misspelled)
getIdComponentItertor() to find the objects corresponding to A and B.

Right now I'm not sure what kind of tedious code could be replaced by XML based
directives, but already I grow tired of writing repetitive four line
AbstractAction declarations :-)

SwingEngine also exposes much of its internals through find, forget, traverse,
getDescendants etc. that one could use. One could even go the whole hog, and
write java code as part of element text, and include the BCEL, and compile on
the fly, and .. ;-)

As for the question of JDOM dependence, this was an issue for us too.  But the
real kicker here, I believe, is that JDOM is just so darn good. To write using
the javax DOM is a real pain in comparison. A quick look at the Swix source
makes it look unlikely that a JDOM dependency could be factored out.

As for Q2, you mention 'one xml decl' -- but see the insert function in the
source (wow!) and the xinclude (double wow!).  So I guess you can split up your
gui into multiple xml files, and even load some of them over the network.

cheers,
 Nandan.

-- 
Nandan Bagchee


Patriots don't use Linux.

		-- c.o.l.a