Re: Problem with webobject attributes in WOBuilder
Re: Problem with webobject attributes in WOBuilder
- Subject: Re: Problem with webobject attributes in WOBuilder
- From: wojingo <email@hidden>
- Date: Fri, 16 Jun 2006 11:41:25 +0930
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.
Jean-Fancois's post makes a lot of sense to me, given some of the
WOComponent api methods and the reuseable components I have in my
frameworks.
I admit I use WOComponents as controllers a lot of the time but have
also had the same thoughts as Jean-Francois listed below, about writing
Controller/Manager classes to perform controller functionality.
I think this approach would lend itself to easier/more comprehensive
automated testing aswell(maybe).
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.
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.
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.
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