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 You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
