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...
