You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Dave Newton <ne...@yahoo.com> on 2007/02/17 00:54:28 UTC

[OT] Re: [s2] Groovy Actions in Struts 2

--- Ian Roughley <ia...@fdar.com> wrote:
> > I'm not sure what you mean by that... it's just a
> > class; it happens to be compiled on-the-fly during
> > bean instantiation. Not much else is different.
> Yes, but it feels to me like you are reaching back
> into the business service tier to create classes
that 
> are primarily view tier - just feels backwards to
me.  

Wait, what? Which is the "business service tier"? 

I'm not convinced that Actions are "view tier,"
either, since they're really just command pattern
implementations... I suppose the result values tie
them to the view tier, but... boy, I dunno.

Hrm, that'll give me things to think about over the
weekend :)

Dave



 
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Re: [OT] Re: [s2] Groovy Actions in Struts 2

Posted by Ted Husted <hu...@apache.org>.
Most often, the Actions work as an adapter between a view layer and a
general-purpose business facade. Because the Actions select a token
indicating a result, the Actions tend to be bound to some type of
navigational system. A classic Action passes input values to the
business facade, and the business facade returns output values, along
with any error or status messages. (The latter often being indicated
by exceptions.)  By creating a generic business facade, we can use it
with other view layers (which would include unit tests) that utilize
the same business logic, but may implement a different navigational
system.

Of course, since S2 Actions are generic, it would be possible to use
XWork and Actions as a business facade. But, the problem people often
run into as applications grow is that there is not a clear line where
the business facade ends and the web adapter begins.

At my day job, we're moving the UI for our next application over to
Ajax. It's a .NET application, so we are not using Struts, but we are
using a business facade based on a port of Commons Chain. The business
methods are represented as individual commands, some of which call out
to iBATIS.NET while resolving the other business logic. We chain
commands together to create a "transaction script" (to use Martin
Fowler's term).

In our case, Ajax makes the MVC separation very clear. In the last
application, the ASP codebehind would make one or more calls to the
business facade, to populate the various controls and whatnot. In this
application, the various Ajax widgets and whatnot can populate
themselves by making asynchronous calls to a JSON-RPC handler.

The handler is essentially a servlet that acts as an adapter between
the business facade and the Ajax widgets. The cool part is that we are
able to use the exact same business facade that we used with the prior
application with zero-changes. Instead of the ASP codebehind making
the calls, the JSON-RPC makes the same calls on behalf of the Ajax
widgets. We're quite happy with the result. But, the key was that we
clearly separated the business services from the rest of the
application, making them easy to reuse it in a different UI (ASPX
versus Ajax).

(To be clear, we are not using ASP pages at all anymore. Just HTML
pages that call a C# JSON-RPC handler (Jayrock), which I believe is
the same sort of thing as DWR.)

-Ted.


On 2/16/07, Dave Newton <ne...@yahoo.com> wrote:
> --- Ian Roughley <ia...@fdar.com> wrote:
> > > I'm not sure what you mean by that... it's just a
> > > class; it happens to be compiled on-the-fly during
> > > bean instantiation. Not much else is different.
> > Yes, but it feels to me like you are reaching back
> > into the business service tier to create classes
> that
> > are primarily view tier - just feels backwards to
> me.
>
> Wait, what? Which is the "business service tier"?
>
> I'm not convinced that Actions are "view tier,"
> either, since they're really just command pattern
> implementations... I suppose the result values tie
> them to the view tier, but... boy, I dunno.
>
> Hrm, that'll give me things to think about over the
> weekend :)
>
> Dave

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org