Even if this might turn some developers away, I think it is import to be
very clear at this point.
While we are certainly not done developing Swixml, we will not turn it
into a JSP like programming language or general all purpose tool.
Variables, loop, etc. will not have representations in the XML
descriptors.
There a many (I repeat _many_) projects out there, open-source as well
as close source that already support those kind of things.
Swixml is not a one size fits all XML-to-GUI converter and doesn't want
to become such a things. Again, Swixml is suppose to be small and fast;
we certainly don't want to add to the sometimes already sluggish
behavior of a Swing UI. Therefore, every approach that would require to
sub-class most or even all Swing components and widgets has to be dismissed.
The JRE 1.4.x already supports long-term persistence using
java.beans.XMLEncoder and java.beans.XMLDecoder.
http://java.sun.com/products/jfc/tsc/articles/persistence2/#jcp
For Swixml this means that there is no need to add to this persistence
mechanism, which allows to serialize complete Swing UIs into an XML format.
Like mentioned already, Swixml is not done. I.e., we'll add action maps,
which will result in not having to subclass SwingEngine anymore.
However, the overall approach is not going to be changed or widely
expanded for the foreseeable future.
Wolf
--
Wolf Paulus
MSCS, SCJP, Sr. Software Engineer
C a r l s b a d C u b e s
mailto:[EMAIL PROTECTED]
CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
