> From: "NIJDAM,MARC \(HP-Cupertino,ex1\)" <marc_nijdam at hp.com>
> [...]
> Looking at this some more (pardon my slow brain on friday...), doesn't this
> look _a lot_ like windowSpec in vw terms?! If tagname was the class and the
> attributes parts make up the message with values that you want to send, this
> would be exactly like windowSpec. Difference here is the ordering constraint
> on messages in ST and the "odd" syntax...

Sounds on target to me. As for "odd syntax", that part of my brain
was frozen about forty years ago... that's why I'm an architect ;-}>

Luckily the sytactic portion of the representation is pluggable.
Just define a new kind of UiSpecReader that produces a Widget tree.

Perhaps we need something like a CompositeUiSpecReader that knows
how to "sniff" an external UI spec and figure out the appropriate
reader to actually use.

*The Task*

Create a class VisualWorksUiSpecReader. Instances of this class
consume a standard VW UI Spec and produce an instance of a WidgetSpec tree.

The existing code should do its backend stuff without any changes.

*The Benefits*

Take advantage of VW NC UI Painter to paint application screens.
We could paint screens in VisualWorks NC using its UI Painter and use
its results without further translation.

Enhanced portability between VisualWorks, ST/X and Squeak.
Zum Beispiel, ST/X uses the VW UI spec to specify its screens.
(ST/X is a VERY VERY VERY fast implementation of Smalltalk
in which one can deploy *serious* production applications.)


*The Challenge*

Perform this task in an XP fashion. Find a programming partner and
write unit tests that ensure that for each of the VW UI Spec constructs
the result is an appropriate instance of WidgetSpec. Then implement
the simplest possible code that passes those tests.

Any takers???

[|] John Sarkela :-}>
ReThink Systems, Inc.