[Seaside] novice question: WATask vs WAComponent
avi at beta4.com
Thu May 13 01:59:52 CEST 2004
On May 12, 2004, at 4:22 AM, Vadim Kolontsov wrote:
> Is it OK to assume that WATask is a "Controller" and WAComponent is a
> "View" in MVC terms? What is the main difference between them? As far
> as I understood, I can think about WATask as "invisible WAComponent
> without any pages", right?
I don't like "Controller" and "View" because they are so overloaded.
But yes, in general WAComponents model pieces of interface whereas
WATasks model pieces of workflow. The distinction is a little fuzzy,
however, since a component may well have workflow in an action method,
and you can embed a task anywhere you can put a component (what will
show up is the components the task calls).
I generally think of WATask as a component with a single "go" link that
gets clicked automatically, before the user even has a chance to see
it. That's probably because it has occasionally been implemented as
precisely that. But "invisible component" is another reasonable way to
think of it.
> For example, I'm implementing a classic "login form" component. It
> should ask login/password (text form), it allows to remember it
> between sessions (checkbox & cookies), it can show "incorrect login"
> inside of form (without any intermediate pages), it allows to register
> new user (using call to another component) and should be emeddable
> into other components. I'm going to use a simple loop, which will run
> until the user enters the correct login/password.
> What is the best way to implement it? Should I use WATask or
> WAComponent? A pointer to list archive would be OK (although I've read
> almost all messages already :)
Well, clearly you will need to implement some WAComponents for this -
the login form itself, the new user registration pages, and so on. The
question comes down to, should the looping logic be put into the
LoginForm, or into a LoginTask that makes repeated calls to a
LoginForm. The nice thing about the latter is the LoginForm becomes
more reusable in the future - someone could implement a different Task
that changed the logic (for example, only allowed three tries and then
locked you out). But the former is probably easier to implement, and
so that's what I would probably do first, and then decide whether it
was worth it to refactor into the more flexible approach.
If you're asking about Seaside ideology in general: I try to make most
of my components be as functionally pure as possible (simple
call/answer interface, no side effects, only calling other components
that are intimately related to them), and put the workflow logic,
database interaction, etc into a few "hub" components or "wizard"
More information about the Seaside