Struts/Motif

[Dan Connelly <ds...@adelphia.net>]

Struts for Motif.  Okay, wash my mouth out with SOAP!

But, look, lots of neat, old X/Motif applications were written using the MVC
architecture.

What good did it do X, Motif, ... or MVC?

And, don't try blaming it all on the X Server being such a heavy "client".
On the other hand, don't try to claim that the Web-way is the only way.

[We could also consider Struts for Swing, but that clouds the argument I am
about to make.]

A Motif MVC app I recently worked on had MVC features similar to Struts,
like an action map "digester".  Well, the Motif app digester was written in
awk and it was a preprocessor.  The mappings got compiled into the code.
But it was similar, a nice high level view of the internal data
architecture.


Unfortunately, I also see some disturbing similarities between the
weaknesses of MVC Motif (as commonly programmed) and Struts, such as



    1.   A difficult and impoverished widget set.

For instance, do we have a high-level Tree widget to plug into Struts?
Having third-party Tree widgets and scripting hacks for Trees didn't make
Motif competitive with the Win-mill.  ( ?? "COMpetitive"  ??)

     2.  Ad hoc Database-to-Model mappings.

For instance, if a number of browser sessions, perhaps hierarchically
related browser sessions, are looking at the same Persistent EJBs, how do
these sessions coordinate their separate (hierarchical) Models?  Their
database updates?  Their screen Updates?   Is this to be left to the realm
of "Business Logic"?   It's system logic, for sure.    It invites trouble to
let the bit jockeys be responsible for getting this right, for buggering the
MVC.


The Motif MVC app I worked on used the windowing hieirachy in X/Motif to
build a Model hierarchy of database views.  This was very ad hoc, very
quirky and quite buggy, but nice.  Or so I thought.   The nuances escaped
many in the user community.  And, eventually the programmers also lost track
of the ad hoc programming needed to sustain the Model hierarchy.   So it
goes.

But, jeez, it did make for a very lively GUI when it all went well, with
model changes rippling from window to window.  Made Win-doze apps look
absolutely static in comparison.  Unfortunately, I don't see much (yet) in
Struts to make a more dynamic display out of (hierarchical) web browser
sessions.   Or, is this just a feature in search of an audience??


Dan Connelly

Re: Struts/Motif

["Craig R. McClanahan" <Cr...@eng.sun.com>]

See intermixed.

Dan Connelly wrote:

> Struts for Motif.  Okay, wash my mouth out with SOAP!
>
> But, look, lots of neat, old X/Motif applications were written using the MVC
> architecture.
>
> What good did it do X, Motif, ... or MVC?
>
> And, don't try blaming it all on the X Server being such a heavy "client".
> On the other hand, don't try to claim that the Web-way is the only way.
>
> [We could also consider Struts for Swing, but that clouds the argument I am
> about to make.]
>
> A Motif MVC app I recently worked on had MVC features similar to Struts,
> like an action map "digester".  Well, the Motif app digester was written in
> awk and it was a preprocessor.  The mappings got compiled into the code.
> But it was similar, a nice high level view of the internal data
> architecture.
>
> Unfortunately, I also see some disturbing similarities between the
> weaknesses of MVC Motif (as commonly programmed) and Struts, such as
>

Well, that is what you get for using a version 1.0 product :-)

The tag set to date has been focused on getting the most basic possible
functionality completed and standardized, so that people can use it.  Now that
we are nearly there, we can start thinking in earnest about future directions.
I've got a few "crystal ball" comments scattered below about where I would like
to see us go next.

>
>     1.   A difficult and impoverished widget set.
>
> For instance, do we have a high-level Tree widget to plug into Struts?
> Having third-party Tree widgets and scripting hacks for Trees didn't make
> Motif competitive with the Win-mill.  ( ?? "COMpetitive"  ??)
>

I see two different development directions here:

* Fancier general purpose tags or tag sets (ok, "widgets" for you GUI hackers
:-)
  like a tree, that can be easily configured with custom tags -- and interacting

  with the bean model and other tags that already exist.

* Application-specific tags that know how to render specific kinds of objects
  in a variety of ways that can be configured with attributes or nested
elements.

>
>      2.  Ad hoc Database-to-Model mappings.
>
> For instance, if a number of browser sessions, perhaps hierarchically
> related browser sessions, are looking at the same Persistent EJBs, how do
> these sessions coordinate their separate (hierarchical) Models?  Their
> database updates?  Their screen Updates?   Is this to be left to the realm
> of "Business Logic"?   It's system logic, for sure.    It invites trouble to
> let the bit jockeys be responsible for getting this right, for buggering the
> MVC.
>

Session management is certainly an area where we can do a *lot* more to assist
app developers get it right.

General database-to-model mappings already exist in many forms, and to some
degree it doesn't matter which ones you wish to use with Struts.  I'm not yet
convinced we need to annoint a particular package as the "one and only" for
Struts use, but we should start creating examples that explore the abilities of
various packages.

>
> The Motif MVC app I worked on used the windowing hieirachy in X/Motif to
> build a Model hierarchy of database views.  This was very ad hoc, very
> quirky and quite buggy, but nice.  Or so I thought.   The nuances escaped
> many in the user community.  And, eventually the programmers also lost track
> of the ad hoc programming needed to sustain the Model hierarchy.   So it
> goes.
>

Just as we can get more sophisticated in our support for the "view" component of
MVC, you are asking here for more sophistication in the "model" component.  This
is an area of interest to me, and I also have some colleagues at Sun that would
be interested in expanding and codifying design patterns for interactions
between web tier applications and EJB-based back ends.

Already on the 1.1 TODO list is some thoughts about possible improvements in the
"controller" component as well, with the idea of workflows (scripted processing
of finer grained logic components than Actions) and event listeners.

>
> But, jeez, it did make for a very lively GUI when it all went well, with
> model changes rippling from window to window.  Made Win-doze apps look
> absolutely static in comparison.  Unfortunately, I don't see much (yet) in
> Struts to make a more dynamic display out of (hierarchical) web browser
> sessions.   Or, is this just a feature in search of an audience??
>

I don't think so -- I think you're seeing the results of "beginning at the
beginning" so far :-).  Continuing to use Windows as an example, it took them
three major revs to even get close to doing this entire picture correctly.
We've got the opportunity to take advantage of emerging web technologies, plus
an open source development model, so there's a potential to move pretty fast.

Future developments in Struts are going to be exciting -- but, at the same time,
I'm going to do my absolute best to make sure we don't de-support folks who
build apps on 1.0 by changing APIs in incompatible ways.

>
> Dan Connelly

Craig