Mainly because with code-generation, you
can’t actually be using the same objects in the builder as the user will
see in the real-world, so you end up with a symbolic representation of the UI,
and you have to compile-test-code-compile-test, etc.
With a standard, and highly configurable
GUI and some state-saving mechanism (plain-text, xml, your-binary-format-du-jour, I don’t care), then you can have your
builder actually manipulating the same objects live. This drastically reduces the development
cycle in my experience, having had to code the same app on Solaris/Motif,
Windows, and NeXTSTEP back in the day. The NeXTSTEP
GUI was done and hooked into live working controllers while still in the
Interface Builder app. So could
actually whiteboard with the stakeholders directly. I cut weeks off of development, and what
was produced had such a reduced maintenance cost compared to coded GUIs.
With that said,
if you are transparently generating the GUI, and mandate no-tweaking (ie, use GUI Dev tool only) then you do get around the last
point about code maintenance, as you should never have someone touch the
code. But using live instances
during UI creation in my experience has an extreme shortening effect on the
product development lifecycle.
You could still be flexible, if you needed
a widget to be significantly different from the standard – but there, you
subclassed the widget, did a proper development cycle
on it, got it clean, THEN you gave it to the GUI builders. It also allowed the GUI builders not to
be coders, which meant you could have artists and people with Human Factors
backgrounds but little programming actually doing what they’re supposed
to.
It’s all preference at some level,
people. Let’s let this go. Both are valid approaches with
advantages and failings. I just got
annoyed by the “There are no advantages to non-generated GUIs” that
Scott kept putting out there. ;)
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 8:34 AM
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))
RE "Especially if
the tool is one that generates code, I think you have to count on the fact that
there will be a need to tweak it
Why a "need"?
You're implying that if it generates resource files that noone will ever need to
tweak them, countering your own first sentence...
What makes a resource file approach so darn powerful?
Noone has yet to answer this...
AFAICS, a resource file
based tool (or any that provides generated-resource/code round tripping)
is much more prone to lock-in. Look at JBuilder -- they support code round
tripping, but:
1. If you modify the code, you must do it consistently with the way
JBuilder expects to read the code.
2. Because of #1, optimization and change of code-generation style is
pretty much a dead issue
(Resource files severely
restrict what the user can modify, and the code that builds the UI could change
to be optimized. This is no different, IMHO, than placing rules on if/how
generated code can be tweaked.)
I'm a compiler guy, and I
liken this to modifying the ASM code generated by a compiler. Imagine what
would happen if people tweaked the ASM code and the compiler had to re-read
that code and figure out how to display it as "C" code. That's exactly the
same thing as round-tripping souce for a GUI builder. If we wanted that support
in a C compiler, people would be forced to tweak such that the compiler could
figure out what C statements their code represented. Forget optimization, as
most optimizations really mangle the ASM code, so much that there's really no
way to reverse it back to C (or at least back to anything that even resembled
the original C source).
That's why my design is
pluggable (easy to do, thanks to Eclipse)... This allows different toolkits,
persisted forms, visualizations, and styles of code generation (including
round tripping source code if someone else really wants to write it.) If
someone doesn't like the generated code, they can tweak the code generator, not the generated code.
I'm basing my tool around
the style of visual programming used in VAJ (including connections). The way
you use the connections depends on the pattern you want to use. In my book, Effective VisualAge for Java,
I describe several patterns that can be used in the VCE, and there are many
more (and many yet to come).
If connections won't
support the pattern you want to use, then AFAICS, no available visual
tool (that I'm aware of) will support that pattern, and
it's time to rethink UI tools. Not a crazy thought at all; that will happen...
I just don't see it happenning for a while. By being very pluggable, I hope to
From what I've heard of
other tools in development, they're much more restrictive on how you can use
them...