No subject

from this at all - in other words,
the same Controller sub-class that can be run from the command-line
"ControllerRun" utility should be equally
usable with a Struts front-end, a Webmacro template, a JSP page, XML thru
XSL (as the XMLController servlet
in the Expresso XML project demonstrates) etc. If we can do that, then we
have truly separated the model,
view and controller. Effectively, the view becomes the presentation
technology (push or pull),
the controller is, well, the Controller, and the model is represented by the
"State" objects and the
dbobjects they use and interact with. I've done some work recently on
"State" to make it an independently
sub-classable object - e.g. not something that is only contained in the
Controller object - which I think
answers the thought of making a cleaner controller/model separation.

Having said that, I'd still very much like to echo Pete's request for input
on this topic, as the more eyes and different viewpoints applied the
better - particularly in this case.

To answer Pete's question:

> Are we committing to a specific approach because we have evaluated it as
> the best practice?

I guess I'd have to say that we're not committing to a specific approach at
all - but allowing the best approach
to be used depending on the specific application. I have code contributed
that I'll be integrating soon that
provides a servlet to interface Controllers to Webmacro, which gives us Text
(if you count that!), JSP, XML/XSL,
straight generated HTML (e.g. ControllerServlet) and soon Stuts. Every time
we do this we learn a bit more about
how the Controller and Model can be kept independent without sacrificing
functionality.

> On the other hand, even
> the best solution isn't worth beans to me unless it has a critical mass
> of other developers moving in the same direction at the same time.

Very true. This is one reason for staying UI/presentation independent,
therefore allowing the developer the choice
of best UI for a given situation. Developers get used to working with a
particular paradigm, and don't want to lose
the productivity gained (or "orphan" existing applications) to move to
something else. While we can't support every UI possibility there is (and
wouldn't want to), I think allowing a good selection of the major choices
will support the widest
possible developer community.

I look forward to the community's input on this very important topic.

Mike
Jcorporate Ltd
http://www.jcorporate.com