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: Fri, 16 Jun 2006 09:24:47 +0100
On 16 Jun 2006, at 03:11, wojingo wrote:
This has been a very interesting discussion, thanks to everyone
involved for the opinions expressed.
Personally, I'm still not entirely convinced about WOComponent
being a controller only and Dynamic Elements being the view objects
as it seems Paul is saying. I see his point but I'm not still note
sure.
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.
Somtimes I need to return view information from WOComponent, such
as, alternate row color css class names for a list of items within
a WORepetition. How else can this be done without using the
WOComponent's java class? That doesnt sounds like the job of a
controller but one for the view objects.
Communicating with views is a controller function; this is entirely
compatible with MVC. It is entirely appropriate for a controller
object to vend view data into the view layer. It is also appropriate
to abstract this information out into a new view class - hence the
ambiguity.
Also the stateless components I use have no controller logic what
so ever, they just generate a view(from the wod+html-template) to
be presented to the end-user as a part of a larger page. Some of my
nested components have only a WOTextField and a WOString inside
with a WOConditional bound to a readOnly boolean. That seems like a
100% view object not a controller.
That's fine.
The more I think about this the less sure I am about what I think
WOComponent is as far as MVC is concerned. I keep coming back to
WOComponent being a View-Controller object that is able to fulfill
either or both roles.
Exactly so. This doesn't mean a breach of MVC rules, just a class
that is flexible enough to live on both sides of the divide.
Paul
Paul Lynch wrote:
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
cheers,
- shaun
_______________________________________________
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