Re: Problem with webobject attributes in WOBuilder
Re: Problem with webobject attributes in WOBuilder
- Subject: Re: Problem with webobject attributes in WOBuilder
- From: Paul Lynch <email@hidden>
- Date: Sat, 17 Jun 2006 16:08:40 +0100
On 16 Jun 2006, at 16:45, Jean-François Veillette wrote:
Le 06-06-15, à 17:27, Paul Lynch a écrit :
View objects are the dynamic elements used within your
components. Model objects are the EOs, the implementors of
EOEnterpriseObject. Controllers are your subclasses of
WOApplication, WOSession, and WOComponent.
While it's true that WOApplication, WOSession and WOComponents
subclasses can make the controller part of the app, I still find
that if I put logic-level decision in there that it render the the
logic-layer reduced to value-holder. Those classes (WO*) can make
for good view-level controllers, but beyond that I find it impose
on them too much responsibilities.
A component is emphatically NOT a view object.
I see WOComponent as the equivalent of NSView. I see WOSession as
the equivalent of NSDocument.
How do you see it ?
I don't think that it is fair to make such tight correlation with
Cocoa. Web and desktop have quite different metaphors and workflows,
but still MVC is a good design principle to use. WOComponent is too
heavy-weight to make an ideal view level object; that is why
WODynamicElement and WOElement (etc) all exist, as well as the hacks
required to make components stateless and reduce binding logic.
As many others say, a lot of application logic that is placed in
controllers really belongs in the model layer.
Even within the wo/html/wod files, their role is to coordinate
between model objects, the EOs, and the user presentation - which
is the final html presented to the user, and not the html files
contained within the wo components.
I would consider this as an hybrid model.
The objects may well be, but can still be used in an MVC way, and
that is what I consider most appropriate. So sometimes you will be
creating components within the view layer, and at others they will be
controllers (in which case you could consider the wo template files
to be loosely analogous to a view layer).
Works fine, but I found that the fact that this layer was
responsible for editingcontext management reduced my logic-layer
almost to value-holder elements.
Thinking about your comment, I am not sure that I understand what you
mean by "logic layer"; in my world, there is just MVC - and, in
common with a number of other WO programmers, I am most satisfied
when the larger portion of my "logic" is in the model layer.
My last big project forced me to rethink about this, since the apps
was sold to another client, which have a different workflow than
the first client it was developed for (keeping the same data
model). What should we do, develop a new app above the same eo
framework ?
Very often, the answer to this is yes. Which is another reason why
the model layer should contain the logic. Incidentally, I prefer not
to think of it as just an eo framework; other types of objects belong
in the model layer as well.
In fact it's a group of apps, so we already have a view-level
(components) framework where many apps share the same set of
components. Should we subclass those shared components just to
have client-specific behaviour ? I'm looking for a design where
I'll be able to keep the logic-level controller on one side and
have the view-level controller on another side. Ideally a design
where the view-level controller will be able to adapt to a model-
level controller without changing the view. It might just be my
current problem, but it also seem that the design used to solve
this problem could be a good practice in general as well.
Focussing on model layer behaviour would seem to resolve this question.
Le 06-06-16, à 09:27, Guido Neitzer a écrit :
On 16.06.2006, at 10:24 Uhr, Paul Lynch wrote:
There is only an artificial distinction between "Dynamic Element"
and WOComponent. All dynamic elements are view classes, and they
are also WOComponent subclasses. So yes, WOComponent fills both
roles.
Nope. WODynamicElement and WOComponent inherit both from WOElement.
Technically correct (my fault), but I believe that my principle stands.
I tend to use page level WOComponent subclasses as "controllers"
and build views as an addition to these "page level" components. So
I have mainly page level objects that control the workflow, the
navigation, validation and so on and I have "drop in" components
that take some information as bindings but nevertheless do only
display things.
Distinguishing between page level components and other components is
useful. However, workflow more properly belongs in the model, and
validation most certainly does. One of the mantras from the Core
Data people helps here - how to validate belongs in the model, when
to validate in the controller.
It seems to me that this layered approach, while good in basic
principle, could lead to a more complex, harder to understand,
application. Or it has done when I have followed it.
A number of these "rules" seem to me to increase complexity rather
than reduce it.
I'll end by stating that I believe that good design is whatever
results in "good" programs, where "good" means easy to develop and
maintain, as well as functional. Rigid design specifications (off-
topic here, I know) lead to rigid program that can only meet a user's
requirements at some moment in time before the application is
actually delivered - and yet user requirements are changing over
time, and also as an application is used. So flexibility of design
is of paramount importance.
Rigidly following rules of any kind won't lead to these good designs,
but MVC as a general principle (and with an emphasis on the M) most
often leads to good designs. As soon as following the principles
prevents good design, it will be time to find something new.
Paul
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden