Re: Problem with webobject attributes in WOBuilder
Re: Problem with webobject attributes in WOBuilder
- Subject: Re: Problem with webobject attributes in WOBuilder
- From: Chuck Hill <email@hidden>
- Date: Mon, 19 Jun 2006 10:32:27 -0700
On Jun 16, 2006, at 8:45 AM, Jean-François Veillette wrote:
Le 06-06-15, à 17:27, Paul Lynch a écrit :
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.
While it's true that WOApplication, WOSession and WOComponents
subclasses can make the controller part of the app, I still find
that if I put logic-level decision in there that it render the the
logic-layer reduced to value-holder. Those classes (WO*) can make
for good view-level controllers, but beyond that I find it impose
on them too much responsibilities.
WOContext is another interesting class to consider for this job in
addition to WOApplication, WOSession and WOComponent.
My last big project forced me to rethink about this, since the apps
was sold to another client, which have a different workflow than
the first client it was developed for (keeping the same data
model). What should we do, develop a new app above the same eo
framework ? In fact it's a group of apps, so we already have a
view-level (components) framework where many apps share the same
set of components. Should we subclass those shared components just
to have client-specific behaviour ? I'm looking for a design where
I'll be able to keep the logic-level controller on one side and
have the view-level controller on another side. Ideally a design
where the view-level controller will be able to adapt to a model-
level controller without changing the view. It might just be my
current problem, but it also seem that the design used to solve
this problem could be a good practice in general as well.
I'd consider layers of frameworks like this:
Model -> Components -> Client Specific -> Application
You may want to add another one for controller / logic level
functionality between the Components and Client Specific one if you
don't want to have that in the Components framework. The Client
Specific layer is responsible for effecting the changes needed for a
specific client, including model, component, and controller sub-
classes as needed and, certainly, workflow. I often use a design
where the Application pageForName method delegates to the client
specific layer which can then choose to return a page other that the
named page. As long as the page returned is a subclass (so that it
conforms to the same API) of the page requested, this can be a useful
technique for client specific customizations.
Chuck
--
Coming sometime... - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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