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: Thu, 15 Jun 2006 22:27:01 +0100
This is my take on it, which is supported by various Apple docs on
WebObjects.
WO tries quite hard to strictly follow MVC. You can find plenty of
evidence for this, as well as exceptions, so it is open to
interpretation. In MVC, you have the three 'layers' of an
application, and objects are assigned to one or another layer.
Objects within any one layer will freely intercommunicate, and will
also communicate freely with an adjacent layer; so model exchanges
information with controller, and controller with view - but never
model with view. That is the only strict requirement of MVC.
One aspect of MVC that people often gloss over is that it is entirely
feasible to have layers within layers, and to constrain communication
across these layers - this can be seen with the many layers within
EOF, for instance. This confuses people looking at WO, but doesn't
breach MVC.
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. A component is emphatically NOT a view object. 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.
However, it is easy to become pedantic about the composition of
classes in the system; what matters most is the efficiency of
development, maintenance and reuse of code. MVC is merely means, a
very well proven means, to that end. One of the most powerful tools
we can use to assist this is the subdivision of the controller layer
into elements that are responsible for smaller units of work (which
is what I read from the two quoted posts). Hence I would say that
these are aspects of the controller layer, rather than reclassifying
them into the view layer, which I feel is incorrect.
Paul
On 15 Jun 2006, at 14:53, Jean-François Veillette wrote:
I was hoping to handle the View entirely in .html + .wod, so if
the .css changes I just change the references in there. However,
the .wod logic won't cope with that, so I have to extend the View
to include a chunk of Java code. Still MVC as long as I separate
it from the Controller code. However, I'm stuck with the
WOComponent being part of the View, and also the Controller due to
pageWithName. Javascript isn't an option as our client has it
turned off for security policies.
I suppose it's just the nature of webapps that the "Page" is both
View and Controller, though it's good to separate these code-
wise. WO makes a good attempt at this, as long as the View logic
doesn't go beyond boolean.
I would consider this as a common misconception of WebObjects.
- WOComponents are 'view' objects, depending on your tolerance
level, you can use an hybrid model where you put some controller in
there, but by design, they are view. look at the WOComponent api,
it seem it was designed to be a view.
- .wo/* files (.html, .wod, .woo) are just utilities, facilities so
that you do not have to use printf like commands
(response.appendContentString, etc.) in your class to generate the
display stream. The .java is the implementation of the view
object, the .wo is a webobject facility to build response based on
a template. for few leaf component (no subcomponents, small/
simple), I have no template (.wo), I add things in the response
directly.
- you put in the view object (the java class and the related .wo
resource) whatever you need to build a quality view over your
model. the richer the interface will be, the more code you will
have in there. if above of that you put workflow control, context
management, then you end up with a class that is too big for an
easy read.
- we too often miss an opportunity to create a new class, that will
control the workflow of the many views of the system. we too often
sparkle bit and pieces of our controller logic as part of the view
logic. sometimes this hybrid model fit just right, but it too
often decimate the workflow control over the many other (views)
objects. we should discipline ourselves to write separate view-
level controller class (page workflow). and not hesitate to add
model-level controller (logic workflow, editingcontext management,
etc.).
- we often think that web apps are different from desktop apps.
why should they, why in a desktop app we use notification mechanism
to pass changes information from the view to the controller/view
objects, why don't we use it in a web app ? I can see many
historical reason to treat web app as a group of rich web pages,
but by design I do not see any reason why we keep that model. yes
by default the rr-loop is different from a desktop app, but now
with rich html web app (ajax etc.), the gap is closing, there is
almost no difference anymore.
I do not have an easy answer yet on on how a webobjects app should
be written. I have tried few things recently, I have not yet found
a wining design / practice. but at least I have ruled out some
practices.
- jfv
... who is still questioning himself
_______________________________________________
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