Re: Problem with webobject attributes in WOBuilder
Re: Problem with webobject attributes in WOBuilder
- Subject: Re: Problem with webobject attributes in WOBuilder
- From: Jean-François Veillette <email@hidden>
- Date: Fri, 16 Jun 2006 11:45:40 -0400
I find this discusion very interesting. I'm very glad people
contribute with their own point of view !
First, correcting myself.
- 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.).
Just to clarify myself a bit, I have found that having a separate
model-level controller, responsible of logic workflow and
editingcontext management, was mostly enough to put the last view-level
controller decision (mostly page workflow) in the component class
itself.
However, I have read recently (I think it's Pierce T. Wetter III
comments) that we underuse DirectAction for most of your navigation
needs.
I have not tried it yet, but I can see that it could allow
centralization of navigation workflow decisions (which will ease
automated testing). It's something I will try next.
My current problem is that while a problem logic impose some workflow,
the implementation of it is too often spread across components. Which
leave my model-logic framework missing an important part of what it
should know and impose.
- 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.
Well ... after writing this, I realized that in a web app there is no
way for the application to push information to the client (browser).
That's a big difference that impose a different design. But I still
think that we should model a web app closer to a desktop app than just
a collection of rich html pages. I.E. we would never think of writing
a subclass of NSButtonView just to implement the action to be taken
when we click on it. But it's almost what we do with wocomponents
subclasses. That's almost VisualBasic design model. We too often
choose to write wo apps closer to VB than Cocoa for example.
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.
A component is emphatically NOT a view object.
I see WOComponent as the equivalent of NSView. I see WOSession as the
equivalent of NSDocument.
How do you see it ?
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.
I would consider this as an hybrid model.
Works fine, but I found that the fact that this layer was responsible
for editingcontext management reduced my logic-layer almost to
value-holder elements.
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.
Le 06-06-16, à 09:27, Guido Neitzer a écrit :
I tend to use page level WOComponent subclasses as "controllers" and
build views as an addition to these "page level" components. So I have
mainly page level objects that control the workflow, the navigation,
validation and so on and I have "drop in" components that take some
information as bindings but nevertheless do only display things.
I have not tried this approach. It seem to at least better centralize
workflow decision. An interesting idea, I'll keep that in mind.
Rule 2 - Make subclasses for common tasks (list, edit, inspect, search
... - "controllers") and build subclasses as the "real pages to
display" ("views").
Rule 3 - Use Direct To Web and/or learn from it.
This is something I should do. This an area that I do not know enough
to use and feel comfy about.
How long is it to get at ease with this ? Any good tutorial / sample
code that can ease the learning curve ?
Rule 4 - Use key value coding. YES, KVC rules!
Yes !
Rule 5 - Use ERXThreadStorage instead of the session to have not so
much dependencies there.
I do not use this object, I have seen it proposed as a solution for
things I would have done differently. I would like to see a sample app
that make use of it (simple, just enough to prove the concept). Maybe
just expose a situation where it solve a common problem in an efficient
way.
Thanks to all who responded already, it's a very interesting read !
- jfv
__________________________________________________
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden