Sounds
like I'm missing my mark. Bummer. Well, annoy or debate, I gotta do one of them
;)
[Thanks for the kind words, btw]
Can't
see the tool yet -- not ready to show. Getting there, though. I've been low on
free time lately, prepping to teach a patterns class at Hopkins
;)
Wrt
the generated code, I plan to have at least two generators that I'll write --
one that generates VAJ like code, and one that generates XMLTalk or something
like BML or the long-term persistence stuff that Sun does. Not that I
recommend the resource file approach, but I wanted to show it was equally as
easy to do. (Note that I had been planning to do this before this thread, though
this thread has confirmed that folks are interested in something like
that.)
My
hope is that as people see the generated code, they'll give me feedback, or
perhaps create alternative code generators. A kind of community optimization, if
you will...
--
Scott
Oh please, Scott…
you’re less annoying by half than most of the people in the workplace. You
bother to consider this stuff, after all. That’s more than most. I’m beginning to feel that this is a
familiarity/comfort debate, because I can see theoretically how your tool
would serve many of the requirements I would have in a builder. But the resulting code leaves me
feeling uncomfortable, and I think it’s mostly what I’m used to. Where can I see this tool of
yours?
Regards,
Christian.
-----Original
Message----- From:
platform-swt-dev-admin@xxxxxxxxxxx [mailto:platform-swt-dev-admin@xxxxxxxxxxx]
On Behalf Of Scott
Stanchfield Sent:
Monday, January 20,
2003 11:11
PM To:
platform-swt-dev@xxxxxxxxxxx Subject: RE: SWT History and Design
Decisions (WAS: [platform-swt-dev] AWT Toolkit using SWT (was: From Swing to
SWT))
That
depends on the UI builder. Most javabean-based builders use live components to
display what the UI will look like (as does mine). Some even have two
modes: design and "live". "Live" mode basically lets you assemble and test a
UI all at once. I'm not a big fan of live mode as I believe you're apt to get
yourself into some unusual states if you edit on the
fly.
Manipulating the
objects live can be done with either representation. In my builder, I keep a
"live" version of the UI offscreen to take snapshots. I suppose I could expose
that, but I'm not sure. If I do, it'll be a low development priority for me. I
found development in VAJ to be quite quick, and the compile-test cycle didn't
feel like it got in the way. I've actually done live work with customers using
it (and they loved the experience ;)
VAJ
supported (and my builder supports) subclasses, but mine allows easy
framework creation (you can create a GUI and when using it, add components
into that GUI if you provide a containerDelegate specification in the
BeanInfo.)
Bringing
up the HCI/HF end of things is a great point, and where I feel that my
pluggability can really be an advantage. A different set of plugins could be
used to present a different user experience, as well as generate code (or
resource files). Kinda like the way custom tags make it easier for non
programmers to do JSPs (when programmers write the tag handlers), different
manipulations could make a UI easier for
non-programmers.
|