| Newsgroups |
gmane.comp.embedded.carlsbad-cubes |
| Message-ID |
<[email protected]> |
Sounds like some good stuff coming down the pipeline - any chance you
could put the code in a public CVS and we could all follow along and
hopefully help out?
Don
On Wed, 10 Dec 2003 [email protected] wrote:
> 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.
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>