Re: Problem with webobject attributes in WOBuilder
Re: Problem with webobject attributes in WOBuilder
- Subject: Re: Problem with webobject attributes in WOBuilder
- From: Mike Schrag <email@hidden>
- Date: Fri, 16 Jun 2006 08:27:03 -0400
The design of WOComponent seems to be nearly identical to the design
approach Java's Swing JComponent took (who knows, maybe some of the
same people worked on both -- it's very incestuous in the
valley :) ). Swing docs state that JComponent objects are View-
Controller pairs. That is, they can serve as both a pure controller
OR a view/controller depending on how you model things. The
ComponentUI classes clearly map onto .wod/.woo/.html/.xml, though not
all JComponents require this and even when they do, there's often UI
crossover inside the JComponent. Trying for totally strict
separation of view and controller can tend to drive you insane. That
said, it does make me a sad panda when I end up with CSS class
references in my component java code :) .
Another related topic is WOOgnl. When I started WO, I was came from
JSP/Servlet/etc. One of the things I ran into quickly is wanting to
pass a complex page title to my HeaderFooter components. For
instance, HeaderFooter component has a "title" binding -- fairly
straightforward (and easy with <%=...%> stuff inside of tag params
with JSP). If I want my title to be "Mike Schrag's Home Page," then
I have some issues. Who generates that string (localization aside
for the moment)? Technically that string is entirely a view
construct (the next designer may want to change it to "The Home Page
of Mike Schrag"), but because it has a variable stuck in the middle,
it has to be in Java code. If you're trying for strict separation of
view/controller, this is a quandry and really only addressable with
something like WOOgnl. So there are definitely some fairly normal
problem sets that don't ALLOW strict view-controller separation given
a stock WO installation.
As pointed out here, the thing to keep in mind is that your model
should NEVER link against the controller or view (if you see
WOComponent references in your model, it's a HUGE code smell). I
think it was Chuck saying, which I totally agree with, that your
WOComponents should really not contain any smarts. It's so much
easier to reuse (and to setup test cases) when all of the heavy
lifting is done in model objects. I don't personally have workflow
objects like Chuck mentioned, though I'm kind of curious to try them
out now and see how it works out. My WOComponents typically
implement workflow. In certain cases, this can run into
complications, though I tend to find that if I need to reuse a
component in multiple workflows, I can chop out the part that is
reusable into a smaller component, embed it into two higher level
components (one in each workflow), and pass in various action methods
to call rather than implement them internal to the reused component.
ms
On Jun 15, 2006, at 10:11 PM, wojingo wrote:
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.
_______________________________________________
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