[Seaside] novice question: WATask vs WAComponent

Avi Bryant 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" 
tasks.

Avi



More information about the Seaside mailing list