You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Wesley Wannemacher <We...@doubleatrailer.com> on 2006/10/06 16:09:43 UTC

FRIDAY #2 non-MVC pages

Hello,

This is my next question...

When building a struts application, is it a good idea to base everything
on actions? For instance, let's say I'm writing an 'About Us' page or
'Terms Of Service'... Should I build an action to handle them, or just
write the JSP. My assumption is that it would be pedantic to have struts
handle it, but I just want to make sure that there isn't some reason I
don't see that I should struts-ify every page/action.

-Wes

--
Wes Wannemacher
Director of Operations
Double A Trailer Sales, Inc.
wesw@doubleatrailer.com

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


Re: FRIDAY #2 non-MVC pages

Posted by Joe Germuska <Jo...@Germuska.com>.
>>When building a struts application, is it a good idea to base everything
>>on actions? For instance, let's say I'm writing an 'About Us' page or
>>'Terms Of Service'... Should I build an action to handle them, or just
>>write the JSP. My assumption is that it would be pedantic to have struts
>>handle it, but I just want to make sure that there isn't some reason I
>>don't see that I should struts-ify every page/action.

In general, I advise using actions for 
everything, because you never know when you might 
need to intervene in the handling.

It is a little tedious to have to deploy a new 
struts-config.xml for every new page; some 
judicious work with the wildcard based forwarding 
can eliminate a lot of that - set something up 
that automatically forwards to a JSP or a Tile 
based on the pattern match.

Especially if you are exposing URLs that might 
get bookmarked, you don't want to have to change 
them later.

Joe

-- 
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com    

"The truth is that we learned from João forever to be out of tune."
	-- Caetano Veloso

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


Re: FRIDAY #2 non-MVC pages

Posted by Simon Chappell <si...@gmail.com>.
On 10/6/06, Leon Rosenberg <ro...@googlemail.com> wrote:
> you probably want the
> http://struts.apache.org/1.x/struts-extras/apidocs/org/apache/struts/actions/ForwardAction.html

+1 (yeah, what he said)

Simon

-- 
simonpeter.org | simonpeter.com | techbook.info

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


Re: FRIDAY #2 non-MVC pages

Posted by Leon Rosenberg <ro...@googlemail.com>.
you probably want the
http://struts.apache.org/1.x/struts-extras/apidocs/org/apache/struts/actions/ForwardAction.html

:-)
Leon

On 10/6/06, Wesley Wannemacher <We...@doubleatrailer.com> wrote:
> Hello,
>
> This is my next question...
>
> When building a struts application, is it a good idea to base everything
> on actions? For instance, let's say I'm writing an 'About Us' page or
> 'Terms Of Service'... Should I build an action to handle them, or just
> write the JSP. My assumption is that it would be pedantic to have struts
> handle it, but I just want to make sure that there isn't some reason I
> don't see that I should struts-ify every page/action.
>
> -Wes
>
> --
> Wes Wannemacher
> Director of Operations
> Double A Trailer Sales, Inc.
> wesw@doubleatrailer.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

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