| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
Dynamically adding Layout mangers would only make sense if a
layoutmanager would be completely unknown at compile-time and decided
on at runtime.
Moreover, putting the full qualified class name of the parser into the
XML descriptor goes completely against the Swixml philosophy.
Something like this was only done for PLAFs and initClasses, to allow
for none default constructors but doing class-loading his way has all
kind of problems i.e. security, type safety, etc.
To avoid those problems, Swixml introduced Libraries for Tags and
Converters. While these libraries require that the tags and converters
be registered before use, the Libraries are dynamic an allow for
registration at runtime.
Swixml will eventually support SWT. However, most applications are
being built for either Swing or SWT and since speed and size have
always been my concern, Swixml is going to be distributed in 4 jar
files: core, swing, swt, and full. (take a look at the jaxen xpath
implementation, where something like this is done successfully for
quite some time now.)
I'm currently working on extracting base classes for engine and parser,
which are part of the core package. Swing and SWT packages have classes
extending those in the core package. The full package as everything
(core, swt, swing) just the right thing if you don't have to care about
the size of your distribution.
Anyway, Brian also got a couple things right. Like we discussed here
may times, the Layout related attributes are going to be promoted to
tags the XML descriptors certainly need a verison attribute.
Even as we move on the 2.0, SwiXml will remain faster than all the
others. No additional layers must be added on top of the widgets.
SwiXml remains to be smaller and SwiXml does Java GUI generation and
that is all. The dynamic behavior of the user interface, defining the
application's business rules, has to be coded in Java.
Taking about irrelevance, the last time I checked only 20 developers
had voted for Swixml at
http://xul.sourceforge.net/post/2003/12/
Considering the more the 300 registered forum members and the more than
700 downloads we see for every Swixml release, this is a very sad turn
out.
Wolf
On Dec 8, 2003, at 6:45 PM, Brian P Michael wrote:
> All,
>
> I have been working on a version 2.0 implementation that will solve
> the layout dilemma.
>
> I have made many refactoring changes to a possible version 2.0
> release. These changes are in place, so that we can
> make maximum code-reuse advantages for the SWT version of the code.
>
> All the SWT code, will use 90% or more of the Swing code. The only
> major differences will be in the SWTParser and the associated
> classes/converters that get called.
>
> To fix the layout problems, I am adding a layoutLibrary feature,
> almost identical to the converterLibrary feature.
>
> Then we can dynamically add the parser classes for different
> layoutManagers to the LayoutLibrary (e.g. ->
>
> <layout type="flowlayout"
> parser="org.swixml.swing.layoutParsers.FlowLayoutParser" />
> <layout type="absolute"
> parser="org.swixml.swing.layoutParsers.AbsoluteParser" />
> <layout type="borderlayout"
> parser="org.swixml.swing.layoutParsers.BorderLayoutParser" />
> <layout type="gridlayout"
> parser="org.swixml.swing.layoutParsers.GridLayoutParser" />
> <layout type="gridbaglayout"
> parser="org.swixml.swing.layoutParsers.GridBagLayoutParser" />
> <layout type="cardlayout"
> parser="org.swixml.swing.layoutParsers.CardLayoutParser" />
> <layout type="flow"
> parser="org.swixml.swing.layoutParsers.FlowLayoutParser" />
> <layout type="border"
> parser="org.swixml.swing.layoutParsers.BorderLayoutParser" />
> <layout type="grid"
> parser="org.swixml.swing.layoutParsers.GridLayoutParser" />
> <layout type="gridbag"
> parser="org.swixml.swing.layoutParsers.GridBagLayoutParser" />
> <layout type="card"
> parser="org.swixml.swing.layoutParsers.CardLayoutParser" />
> <layout type="jgoodies.form"
> parser="org.swixml.swing.layoutParsers.JGoodiesFormLayoutParser" />
>
> The parser has two major methods, buildLayout() and applyLayoutData().
>
> I have a good bit of the code done already. And the tests are going
> quite well. My only problem is with
> absolute positioning, setpreferredSize and other non-layout manager
> issues. I am trying to make sure
> all types of layout can be included.
>
> I should be done with the first cut of version 2.0 by end of year and
> will release that to Wolf for review.
> After Wolf's review, he will determine where to go from there.
>
> The change to a flexible layout manager includes providing two new
> tags, <layout type="abc"> and <layoutdata type="abc">. <layout> tag
> will replace the layout attribute completely. The <layoutdata> tag
> will map all necessary features to manage the "constraints" data.
> But, unlike the constraints attribute, this will be an all XML tag.
> The constraints attribute than will be obsoleted as well.
>
> When the parser finds an object with a <layout> tag as a child, we
> process the <layout> tag.
> When the parser finds an object with a <layoutdata> tag as a child, we
> process that tag and apply to the
> object creation (or in the favor of absolutePositioning, will apply
> the setLocation or setPreferredSize.
>
> I need to write a converter that will converter version 1.0 xml files
> to version 2.0.
>
> If you want to create a new LayoutManager, then you will be able to
> (also, if you feel we haven't done the best at implementing
> a specific layoutParser, the code will be quite isolated and can be
> improved/fixed easier.
>
> For examples.
> E.g
> taken from the GridBag.XML Sample file:
>
> Version 1.0 Style:
>
> <button name="btn4" text="Swing">
> <gridbagconstraints insets="2,2,2,2" gridx="1" gridy="1" ipadx="0"
> ipady="0" weightx="1.0" weighty="1.0"/>
> </button>
>
> Version 2.0 Style:
>
> <button name="btn1" text="Wonderful">
> <layoutdata id="gbc_1" type="gridbag">
> <gridx>0</gridx>
> <gridy>0</gridy>
> <gridwidth>15</gridwidth>
> <gridheight>1</gridheight>
> <weightx>1</weightx>
> <weighty>1</weighty>
> <fill>none</fill>
> <anchor>southwest</anchor>
> <insets>
> <top>2</top>
> <left>2</left>
> <bottom>2</bottom>
> <right>2</right>
> </insets>
> </layoutdata>
> </button>
>
> For more info, I have also added versioning of XML files to the system.
> For version 1.0x files, no version will be needed.
>
> The version 2.0 code will look for the following
> <swixml version="2.0">
>
> add determine that is version 2.0 (or whatever).
>
> A 2.0 parser will then be used for version 2.0 and a 1.x parser will
> be used
> for parsing 1.x files.
>
> Also, to determine the engine type, SWT or SWING, a separate tag will
> be added.
> <engine type="swing"> or <engine type="swt">
>
> The engine type will then dynamically tell which "engine" to use,
> Swing or SWT.
> The cool thing will be that you will be able to use one XML file and
> include both
> SWT or SWING templates in it. You could then switch to a different
> engine, like SWT if it looks
> better on a specific platform, like Linux. The GTK version of SWT is
> pretty nice.
> But you could run the SWING version of the template on Windows and Mac.
>
>
> I also expect to create a generic, SWEngine.render(filename,
> EngineType) where engineType is either "SWT" or "SWING".
>
> If there are any comments, feedback would be appreciated.
>
> Thanks
>
> Brian P Michael
>
>
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.