Re: Struts MVC design

[Rick Reumann <st...@reumann.net>]

Michael Jouravlev wrote the following on 7/6/2005 5:03 PM:

> The action class
> provides the event contract, while the action form does the dirty
> work.  

Well in this case the struts-config file would provide the contract and 
you could simply use one ForwardAction for everything. You've 
substituted numerous Actions (or DispatchAction methods) and replaced 
them with either A) numerous ActionForms (probably sharing the same 
field names or B) complext logic in single ActionForms to decide on what 
'business logic' to do.

> Did I convince you that having business logic in an action form is
> better? Action class provides external I/O contract and manages
> messages and navigation, while action form performs operations on
> business data, *where it is actually stored* .

No you haven't convinced me at all:) I still see no practical benefit to 
flipping struts inside out like this. Sure it'll work, and I'm not even 
saying (without a lot more thought:) that it's "bad," but it certainly 
totally turns around the way the framework was designed to work. (I 
don't think the method names "reset" and "validate" would be chosen as 
method names in an ActionForm if they were designed for doing all kinds 
of business logic in them.

I think if you go this route, you should say it's a different version of 
Struts.. maybe StrutsWorks or something:) Under the scenario you've 
proposed I don't see what the point of using any Actions would be? Why 
not just use the one default FowardAction and do everything in the 
ActionForm?

(In case someone is popping into this thread late, I'm certainly not 
advocating this:)

-- 
Rick

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

Re: Struts MVC design

[Craig McClanahan <cr...@gmail.com>]

On 7/6/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/6/05, Craig McClanahan <cr...@gmail.com> wrote:
> > On 7/6/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> > >
> > > Now there is talk of Struts in the future containing ActionCommands
> > > which can be substituted in place of Actions, and strung together in a
> > > chain, and presumably can perform View-Controller logic.
> > >
> >
> > If you look at Shale (with its support for both ViewController and
> > Dialog -- which, among other things, lets you intersperse action
> > states and view states to your heart's desire), you'll find that the
> > future is now :-)
> >
> >   http://struts.apache.org/shale/
> >
> > Craig
> 
> Moved to the new thread.
> 
> From http://struts.apache.org/shale/features.html#view
> 
> "Each backing bean that implements ViewController will support a
> boolean property postback, which will be set to true if this view is
> the one that is processing a form submit previously rendered by the
> same page, or false if this view was newly navigated to."
> 
> * How is this different from ASP.NET?

The ViewController part of Shale is indeed very similar to the way
that ASP.NET implements the View Helper design pattern.  From a
usability perspective, especially for developers not as well versed in
object oriented programming concepts, Microsoft got this right --
which was one of the motivations for JSF making the same style easy to
accomplish in Java.  When you are focused on a particular page, it is
very convenient to think of everything that happens related to that
page being a response to a particular event -- with all the events for
a particular page conveniently represented as public methods on a
single backing bean (code behind file in ASP.NET terminology).  The
prerender() method, as well, performs exactly the same function as the
Controller interface in Tiles -- it provides a perfect place to
acquire resources that are *only* required if you are the page that is
going to be rendered.

Struts 1.x supports exactly the same paradigm; it's just not as pretty
-- a setup action that preceeds the rendered view action. 
ViewController doesn't require you to do that extra step (or try to
deal with the problematic action chaining issues that plague Struts
1.x, when you submit to the processing action for the previously
rendered form, then need to navigate to the setup action for the form
about to be rendered).

And, if you go on and also use the Dialog feature of Shale, you can
have as many different action states (each represented by a method
call, expressed as a method binding expression so the business logic
classes need have no knowledge of JSF or Shale) as you want in between
your views.  So, if you like the way a chain of responsibility pattern
(like Commons Chain) lets you decompose business processes into fine
grained reusable chunks, you can do that too.

> * Does not this make Shale page-based instead of front-controller
> based? MS recognized lack of front controller support in ASP.NET 1.0
> and will provide it to the second version.

No, it makes the *ViewController* part of Shale page based, as it should be :-).

The rest of Shale (in particular the controlling filter where you can
plug in anything that is supposed to happen once per request, like an
authentication filter) is still a front controller.  You can impose
whatever overall processing you want on each request, simply by
composing the Commons Chain command that the filter applies to each
request.

Besides the biggest difference (from Struts) of being JSF based, this
architectural principle is the second major difference in Shale, and
it results from the most important lesson I've learned by watching how
people use (and misuse) Struts -- the controller framework should
consist of fine grained components that can be combined or customized
as necessary to meet particular application requirements.  If a
particular application needs, say, authentication filtering, then plug
it in.  If that app also needs logging, or tracing, plug that in too
(no having to worry about subclassing RequestProcessor and then
running into Java's single inheritance limitation.

At the same time, it is up to the application architect if they want
to build up the specialized processing needed for an individual
request by composing with reusable logic blocks.  You can do this
easily with Shale, either by calling common reusable code chunks from
methods like prerender() and destroy() when using ViewController, or
by composing the action states in between your views when using
Dialog.  The front controller managing the entire application need not
be involved in figuring out what specialized resources the particular
processing path for a given request will need -- although you could
even do that in the application level filter, if you really wanted to.
 Your choice.

What's interesting about the current discussion is that things like
DispatchAction and LookupAction, as well as the idea of action
commands, are all an attempt to retrofit exactly the same concept of
fine grained management of individual interactions onto the monolithic
controller of Struts 1.x.  As some have observed, the two approaches
don't necessarily fit together very well -- although you can certainly
do it with some bending and twisting.

But the architectural model of an application that Shale presents to
the developer, once you learn it, is *much* simpler to program to, as
well as being easier to configure.

Craig

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

Re: Struts MVC design

[Dakota Jack <da...@gmail.com>]

Shale may purloin the name "Struts" but their is no Struts to Shale at
all.  Mark G. may or may not harm Struts (I don't think people are so
stupid as to let that influence their career decisions actually) but
Shale will kill Struts utterly, if Shale, which is very unlikely,
should be chosen to supercede Struts.

On 7/6/05, Michael Jouravlev <jm...@gmail.com> wrote:
> On 7/6/05, Craig McClanahan <cr...@gmail.com> wrote:
> > On 7/6/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> > >
> > > Now there is talk of Struts in the future containing ActionCommands
> > > which can be substituted in place of Actions, and strung together in a
> > > chain, and presumably can perform View-Controller logic.
> > >
> >
> > If you look at Shale (with its support for both ViewController and
> > Dialog -- which, among other things, lets you intersperse action
> > states and view states to your heart's desire), you'll find that the
> > future is now :-)
> >
> >   http://struts.apache.org/shale/
> >
> > Craig
> 
> Moved to the new thread.
> 
> From http://struts.apache.org/shale/features.html#view
> 
> "Each backing bean that implements ViewController will support a
> boolean property postback, which will be set to true if this view is
> the one that is processing a form submit previously rendered by the
> same page, or false if this view was newly navigated to."
> 
> * How is this different from ASP.NET?
> * Does not this make Shale page-based instead of front-controller
> based? MS recognized lack of front controller support in ASP.NET 1.0
> and will provide it to the second version.
> 
> Resource-based apps like Struts Classic can return whatever page they
> want from the same location, while page-based apps tie resource
> address to a page, which can lead to unfriendly Back experience. This
> can be worked around, but why if Struts Classic already provides
> better approach?
> 
> Sure, a component should be able to be initialized when needed. It can
> be done easily with initialization parameter.
> 
> Shale Dialogs is based on Spring Webflow, which, when I checked the
> last time, did not support Back button and clean refresh. Hopefully,
> Shale Dialogs behaves more user-friendly.
> 
> Nevertheless, Struts Dialogs has WizardAction, which provides support
> for dialogs and wizards, based on Easy Wizard concept:
> http://today.java.net/pub/a/today/2005/03/15/webwizard1.htm
> http://today.java.net/pub/a/today/2005/03/29/webwizard2.htm
> WizardAction subclasses DialogAction and implements wizard's UI Controller.
> 
> see the demo: http://www.superinterface.com/strutsdialog/wizardaction.do
> Notice, that Refresh works, and that you cannot go back to a previous
> page (unless you use Opera).
> 
> The above is possible with adding of only two action classes to classic Struts.
> 
> Michael
> 
> --
> Struts Dialogs
> http://struts.sourceforge.net/strutsdialogs
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: Struts MVC design

[Michael Jouravlev <jm...@gmail.com>]

On 7/6/05, Craig McClanahan <cr...@gmail.com> wrote:
> On 7/6/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> >
> > Now there is talk of Struts in the future containing ActionCommands
> > which can be substituted in place of Actions, and strung together in a
> > chain, and presumably can perform View-Controller logic.
> >
> 
> If you look at Shale (with its support for both ViewController and
> Dialog -- which, among other things, lets you intersperse action
> states and view states to your heart's desire), you'll find that the
> future is now :-)
> 
>   http://struts.apache.org/shale/
> 
> Craig

Moved to the new thread. 

>From http://struts.apache.org/shale/features.html#view 

"Each backing bean that implements ViewController will support a
boolean property postback, which will be set to true if this view is
the one that is processing a form submit previously rendered by the
same page, or false if this view was newly navigated to."

* How is this different from ASP.NET?
* Does not this make Shale page-based instead of front-controller
based? MS recognized lack of front controller support in ASP.NET 1.0
and will provide it to the second version.

Resource-based apps like Struts Classic can return whatever page they
want from the same location, while page-based apps tie resource
address to a page, which can lead to unfriendly Back experience. This
can be worked around, but why if Struts Classic already provides
better approach?

Sure, a component should be able to be initialized when needed. It can
be done easily with initialization parameter.

Shale Dialogs is based on Spring Webflow, which, when I checked the
last time, did not support Back button and clean refresh. Hopefully,
Shale Dialogs behaves more user-friendly.

Nevertheless, Struts Dialogs has WizardAction, which provides support
for dialogs and wizards, based on Easy Wizard concept:
http://today.java.net/pub/a/today/2005/03/15/webwizard1.htm
http://today.java.net/pub/a/today/2005/03/29/webwizard2.htm
WizardAction subclasses DialogAction and implements wizard's UI Controller.

see the demo: http://www.superinterface.com/strutsdialog/wizardaction.do
Notice, that Refresh works, and that you cannot go back to a previous
page (unless you use Opera).

The above is possible with adding of only two action classes to classic Struts.

Michael

--
Struts Dialogs
http://struts.sourceforge.net/strutsdialogs

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

Re: Struts MVC design

[Michael Jouravlev <jm...@gmail.com>]

On 7/6/05, Rick Reumann <st...@reumann.net> wrote:
> Michael Jouravlev wrote the following on 7/6/2005 5:03 PM:
> 
> > The action class
> > provides the event contract, while the action form does the dirty
> > work.
> 
> Well in this case the struts-config file would provide the contract and
> you could simply use one ForwardAction for everything. You've
> substituted numerous Actions (or DispatchAction methods) and replaced
> them with either A) numerous ActionForms (probably sharing the same
> field names or B) complext logic in single ActionForms to decide on what
> 'business logic' to do.

I cannot use ForwardAction for everything because I need to dispatch
the button click to a handler. DispatchAction (its subclass) provides
dispatching of events. My ActionForms do not have complex logic, they
have simple methods like crudCreate or crudLoad or crudDelete. These
methods are called from action class. Action class itself can be
reused in different apps or in the same app, because it is stateless.
ActionForm is stateful (has session scope), has specific business code
and properties for every particular business object. Generally,
actionforms are not shared.

> > Did I convince you that having business logic in an action form is
> > better? Action class provides external I/O contract and manages
> > messages and navigation, while action form performs operations on
> > business data, *where it is actually stored* .
> 
> No you haven't convinced me at all:) I still see no practical benefit to
> flipping struts inside out like this. 

I just explained where benefit is: with your approach you reuse forms,
but define specific action classes. I suggest to reuse action classes,
but to define specific forms. Is not it the same thing? I don't think
so, because action classes can define different contracts, for example
for yes/no dialog, or for next/back/cancel wizard of for
create/edit/view/delete form. These action classes can be reused.
Action form works with specific data, so it is natural, that it should
not be reused.

I will think of better reasons ;)

> (I don't think the method names "reset" and "validate" would be chosen as
> method names in an ActionForm if they were designed for doing all kinds
> of business logic in them.

Oops, I see misunderstanding here. I did not say that business logic
should be implemented in reset and validate. Not at all. There are
intefaces, which are implemented by action forms. I hope you will find
time to look at my stuff, because it is explained there and in the
source code.

> I think if you go this route, you should say it's a different version of
> Struts.. maybe StrutsWorks or something:)

You got me: I was thinking of spawning off Struts to something else,
but I would like first to convince its power users and committers,
that the change I am suggesting is good. If this does not work, I may
consider borrowing Struts core, add my stuff to it and call it
StrutsWorks ;) I figured, that to do that I need at least 30% of my
own code, and now I do not have critical mass yet. Another issue is
users, who would learn new controller framework, when there are
exciting alternatives like Wicket?

> Under the scenario you've
> proposed I don't see what the point of using any Actions would be? Why
> not just use the one default FowardAction and do everything in the
> ActionForm?

Right, in many cases I would prefer action form to do the dispatching
and forwarding to a view. But in other cases I would prefer to reuse
standard action class, and to define business methods in a form bean.
So, I don't want to *change* everything, I want to *add* new options.

Michael.

--
Dialogs for Struts
http://struts.sourceforge.net/strutsdialogs

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