On Tue, May 23, 2000 at 03:54:07AM -0400, Chris Kimpton wrote:
> I agree with the proper wrappers bit, but don't get me onto MVC (ie
>http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox.html )
There's some excellent stuff in this article - thanks for the pointer.
In relation to this and what we were discussing I have a few comments:
Holub, IMO, sets up a strawman MVC in this article. MVC != MFC !!!
(And believe me I know from bitter experience about the sad deficiencies
of MFC's design principles - try reading the MSDN article about good MFC
coding practice if you fancy a good laugh). This misconception of the MVC
design pattern is the kind of thing that makes Jon's suggestion of using
'Model 2+1' to describe what we aim for with Turbine an excellent idea.
As it happens his 'PAC' architecture *is* MVC in my book - the three elements
of model, view and controller are there, and as ever the aim is towards
the unattainable ideal of having the three elements entirely decoupled.
However he does have some interesting ideas about how to increase
the decoupling, ideas that do to some extent go against the grain of how
I currently see MVC. I've encountered the idea of having 'model' layer
objects render themselves in the view before, and I've thought "hey
that's nice, but I can't see it being very practical". XXX does do some
work to address this kind of concern, and set out his ideas for making
this work.
So I've got a clearer idea of what you are trying to achieve with your
model objects having an array of 'attribute' objects that can render
themselves as HTML. I guess these objects are like his visual proxies.
That's quite cool, but if I do things this way (as I might, now) I'll
still use webmacro. For instance what you were trying to do coul look in
webmacro like:
<table>
#foreach $attr in $mem.Attributes
#begin
<tr><td>$attr.renderLabel()</td><td>$attr.renderInput</td></tr>
#end
That's quite cool - you've got complete templated control of the overall
appearance of the page, but you've also decoupled yourself from
knowledge of the model object. To get more finegrained control of which
attributes to display on a particular view something like the following
could be used:
#set $attr = $mem.getAttribute("name")
Also note that one thing XXX describes that is not possible directly in
the Turbine architecture is having the visual proxy objects receive
events directly. This is much more natural in a traditional
GUI environment than in a request/response based HTTP environment,
but you can achieve some degree of the same decoupling between
controller and model with that 'setProperties' method of ParameterParser
- particuarly if you see the setXXX methods of your model objects as
being arbritary event handlers rather than property setters.
(Incidentally I was looking at SPFC the other day, whose development
seems to have died a death, and it's quite interesting what they were
trying to achieve with Listener interfaces - it would be possible to
write something similar in Turbine, but I'm not sure it would be worth
the effort).
Anyway thanks for setting me off on this interesting train of thought
and good look with your code...
Sean
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
