Re: Help with code screen using model-view-controller
Re: Help with code screen using model-view-controller
- Subject: Re: Help with code screen using model-view-controller
- From: "Tom M. Blenko" <email@hidden>
- Date: Mon, 12 Jun 2006 15:01:29 -0700
Does anyone know of a good reference or examples that
can demonstrate model-view-controller?
I have found WO apps to be much more difficult to model using MVC
than Cocoa apps. Maybe one reason is because WO is a server-side
technology (ignoring Java Client :-) so Views aren't so obvious. But
one could probably argue that dynamic element classes that generate UI
elements on a Web page are View classes. A typical WO app probably
doesn't contain many custom dynamic element classes, so the main MVC
modeling challenge is probably between Controllers and Models.
But maybe a bigger problem is that WebObjects Builder supports easy
mixing of Model and Controller. I look at Model classes as those that
contain logic that manipulates data without any assumption about the
display of that data. Controller classes are the glue between Models
and Views. So for me, custom WOComponents are Controllers. However,
WOBuilder supports associating data directly with UI elements, so the
data model is exposed to the WOComponent. I tried to fight this at
one point by not typing custom WOComponent keys (i.e., instance
variables and methods) as custom data types (i.e., those property
types specified in an eomodel) instead creating Model classes that
custom WOComponent methods would invoke for data to display and to set
data values. That was a painful process that resulted in much more
bug-prone code. So I gave up on strict Model and Controller
separation.
I don't see the problem -- but perhaps I'm stuck with seeing things
through my own habits (I am strongly in favor of MVC but I think it
means what you find it means in the technology you are using). MVC
Cocoa looking a bit different than WebObjects seems unsurprising.
(Views in WebObjects applications have very different lifetimes than
typical views in Cocoa applications, for starters).
I agree with Chuck that .wod+WOComponent is the controller. I think
this addresses your WOBuilder issue.
I rarely have trouble deciding where something goes. If I want to fetch
all the Users, or all the Users subject to some qualifer, I can
implement methods for fetching (and generating the qualifier) in User.
If I want to cache the result, I'll do that on the page/in the
controller. Or occasionally on the Session (a super-controller for the
page) for, e.g., content shared across pages.
I admit to creating qualifiers, sometimes, or doing subselects using
filteredArray(...), in the controller. Or using EOUtilities methods
directly on the page when I could create a simple wrapper for them in,
e.g., the User class. If I use the same fetch or qualifier twice then I
will move it to User. So perhaps those are MVC violations but I
attribute them to laziness, not to confusion about MVC in a WebObjects
setting.
The in-memory subselect as a model method seems a little odd because I
want to do the selection on an NSArray that has been fetched via User
and then cached on the page.I have to pass the NSArray back to the User
method to do the subselect. Doesn't look unreasonable from the User
side, though: what it implements is perfectly logical and does not
depend on the caching property implemented by the controller. So I say
it separates the properties well between the controller and the model
and that's the way it should be.
Looking through some actual model classes here, I find myself importing
com.webobjects.appserver to load WOCookie, or com.webobjects.eoaccess
to get access to EOUtilities. Maybe a small error by the designers, or
perhaps they had something a little different in mind in sorting these
out. I'm not bothered by this.
So what is a concrete example of a problem that doesn't have a clear
MVC separation in WebObjects?
Tom
_______________________________________________
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