Re: Renderers and Editors
"Wolf Paulus" <[email protected]>
| Newsgroups | gmane.comp.embedded.carlsbad-cubes |
|---|---|
| Message-ID | <001001c39445$13b4dbe0$8f02a8c0@WPAULUSXPP650> |
Swixml is neither perfect nor complete and even with the syntax approaching
1.0, I assume we are going to add new features very soon.
However, Swixml never wanted to be everything to everybody - and we will
probably never see scripting or some sort of design time control being
supported by the core Swixml library. The "refid" attribute ( to re-use
reuse a set of attributes already set in another tag) is probably the
closest we will ever get to have variables in a Swixml descriptor.
Swixml is a GUI generating library that should be considered by Java/JFC
developers who don't like GUI-code generators / wizards and also prefer a
design that separates the layout from the biz-logic.
That said, I agree that the line between layout and logic gets blurry
sometimes: i.e. combo box with a static set of options, table headers,
simple cell renderer, editors, etc.
At this point, I'm not able to outline what features are going to be added
when but I'm open for suggestions - in fact I'm glad to see some more
activity in the forum lately. However, every improvement we are going to
make has to fit in the overall picture. Let me point out a couple issues
that are important to me:
Speed: New features must not negatively influence the overall agility of the
UI.
Size: Swixml was originally influenced by the Thinlet project. Even with
high bandwidth network connections available, size still matters - therefore
the introduction of required or depended libraries is somewhat unlikely.
Syntax: So far only six JFC classes needed to be extended; the methods added
are few and short. This strategy ensured that Swixml didn't spin-off into an
all-new GUI description language but stayed close to JFC/Swing.
SWT: Swixml is just some factory and reflection magic around the JFC/Swing
objects and their bean style methods. The org.Swixml.Parser class implements
swing rules that are not captured inside the JCF classes but describe how
the object need to be assembled / composed. Considering all things, I'm kind
of reluctant to jump on the SWT bandwagon. However, the recent Mac OSX
(Mac/Carbon) support could me make reconsider. I certainly need more details
on SWT support on MAC OS X.
I'm just about to finish a Swixml GUI (Rich Webstart client for server
administration), containing 20 Swixml descriptors. The resulting jar is 1.8
MB (containing pieces of JDOM, Jaxen on the Incors LAF). I think, out of
this project, I got a pretty good understanding where Swixml needs to be
improved the most, and layout, rederers, and editors certainly come to mind.
There are a couple of things however, you can do right now.
For instance, a formatted text field can be used like this:
<formattedtextfield id="tf_TicketTime" columns="5"
initclass="java.text.DecimalFormat(#0.00)"/>
Moreover, we extended a couple core JFC classes and added some setter and
registered the new classes with the original names.
/**
* Registers all SwiXML tags needed to run the admin client.
*/
public static void registerTags() {
if (REGISTER_TAGS) {
// register resource bundle
SwingEngine.setResourceBundleName(Constant.BUNDLE_NAME);
// register converters
PrimitiveConverter.addConstantProvider(CharSetConstants.class);
PrimitiveConverter.addConstantProvider(SearchModeConstants.class);
// register tags
SwingEngine swix = new SwingEngine();
swix.getTaglib().registerTag("Button", XButton.class);
swix.getTaglib().registerTag("FormattedLabel", FormattedLabel.class);
swix.getTaglib().registerTag("Legend", Legend.class);
swix.getTaglib().registerTag("LocationBar", LocationBar.class);
swix.getTaglib().registerTag("MenuItem", LOJMenuItem.class);
swix.getTaglib().registerTag("Menu", LOMenu.class);
swix.getTaglib().registerTag("OKCancelPanel", OKCancelPanel.class);
swix.getTaglib().registerTag("SearchBar", SearchBar.class);
swix.getTaglib().registerTag("StatusPanel", StatusPanel.class);
swix.getTaglib().registerTag("TextField", RestrictedTextField.class);
swix.getTaglib().registerTag("ToolBarButton", LOToolBarButton.class);
REGISTER_TAGS = false;
}
}
----- Original Message -----
From: "Gabe Hicks" <[email protected]>
To: "List for Users of Carlsbad Cubes' Technologies and Products"
<[email protected]>
Sent: Thursday, October 16, 2003 1:06 PM
Subject: Re: [Forum] Renderers and Editors
> The big idea for me is this line in the Swixml
> summary: "However, all dynamic and data-depending
> objects, like event handlers, data models, etc, have
> to be coded in Java".
>
> Wolf:
> Do you consider setting the default icons in a tree a
> dynamic behavior? Or telling it what node editor it
> will use. If this is defined only once per GUI obect,
> it really blurs. I think the renderer is
> unquetionably not a dynamic or data-depending item.
> As for the editor, how is that different than
> specifying init-class for a model?
>
> --- kate rhodes <[email protected]> wrote:
> > many of us do consider them layout but wolf
> > considers them more a
> > functionality thing so (unless something has
> > changed) not in SWIXML but
> > please see the discussion we've been having about
> > the future of SWIXML
> > and making it easily extendable by third parties so
> > that we can do just
> > that.
> >
> >
> > on a related note, the generic plugin engine I
> > mentioned yesterday is in
> > a "pretty usable state" according to one of the
> > authors.
> > meaning it's probably be fine but a bug may have
> > snuck in and not been
> > caught yet. If you find anything and send a patch
> > they'll update it
> > pretty quickly I'm sure.
> >
> > -Kate
> >
> > Gabe Hicks wrote:
> >
> > >Are there any plans to support setting cell
> > renderers
> > >and editors in the XML file? I consider this to
> > be a
> > >display issue (especially the renderer) and
> > something
> > >that squarely belongs in the View layer.
> > >
> > >=====
> > >Gabe Hicks
> > >
> > >__________________________________
> > >Do you Yahoo!?
> > >The New Yahoo! Shopping - with improved product
> > search
> > >http://shopping.yahoo.com
> > >
> > >_______________________________________________
> > >Forum mailing list
> > >[email protected]
> >
> >http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Forum mailing list
> > [email protected]
> >
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>
>
> =====
> Gabe Hicks
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Shopping - with improved product search
> http://shopping.yahoo.com
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>
>