You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/11/23 15:20:00 UTC

Re: DynaValidatorForm 'forgets' request-attribute on redisplay after validation

Your action isn't executed if validation fails.  However, the 
validation is performed on a second request, so the object placed 
into the scope before the form was presented is no longer there.

If your categories are really relatively static, consider managing 
them in Application scope rather than request.  I often have one or 
more plugins which initialize common menus like states and provinces 
or months of the year and place them into the application scope (I 
like to use the DigestingPlugIn).  Your code doesn't look like 
there's anything particularly request-sensitive about the category 
tree.

Some people make lists a property of the form itself.  This is also 
one of the core use cases for some kind of view controller registered 
against the input forward's path, which is one of my goals to 
implement in a Struts 1.3.x timeframe.

Joe

At 3:09 PM +0100 11/23/04, Alexander Czernay wrote:
>I have a simple DynaValidatorForm
>
>      <form-bean name="categoryForm" 
>type="org.apache.struts.validator.DynaValidatorForm">
>         <form-property name="description" type="java.lang.String" />
>         <form-property name="name" type="java.lang.String" />
>         <form-property name="id" type="java.lang.String" />
>         <form-property name="parent" type="java.lang.String" />
>      </form-bean>
>
>that is called whtin an action
>
>        <action path="/categories-edit"
>            attribute="categoryForm"
>            input="msys.categories-edit"
>            name="categoryForm"
>            scope="request"
>            validate="true"
>            type="de.sbow.struts.action.Categories.EditAction">
>            <forward name="success" path="/categories-edit-finish.do" />
>         </action>
>
>that inserts so data into the request inside its execute method
>
>    public ActionForward execute(
>        ActionMapping mapping,
>        ActionForm form,
>        HttpServletRequest request,
>        HttpServletResponse response) throws Exception {
>              // read CategoriesTree and put it into request scope
>            try {
>                CategoriesModel categories = new CategoriesModel();
>                request.setAttribute(Constants.CATEGORY_TREE, 
>categories.getCategories());
>            } catch (ApplicationException e) {
>                request.setAttribute(Constants.CATEGORY_TREE, null);
>            }
>
>            return mapping.findForward("success");
>        }  
>
>This works quite well during the form's initial display. But if I 
>enter wrong values so that the validation fails, the 
>CATEGORY_TREE-attribute is missing and thus the JSP-view fails.
>
>Isn't the execute-method called again when the validation fails? 
>Anything else wrong here?
>
>Thanks for any help,
>Alexander
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

Re: DynaValidatorForm 'forgets' request-attribute on redisplay after validation

Posted by Alexander Czernay <al...@czernay.com>.

The problem is, that the given form actually edits the categories-tree 
and as it is presented to the user after editing it, it should be 
updated after the form is submitted.

Alexander

Joe Germuska wrote:
> Your action isn't executed if validation fails.  However, the validation 
> is performed on a second request, so the object placed into the scope 
> before the form was presented is no longer there.
> 
> If your categories are really relatively static, consider managing them 
> in Application scope rather than request.  I often have one or more 
> plugins which initialize common menus like states and provinces or 
> months of the year and place them into the application scope (I like to 
> use the DigestingPlugIn).  Your code doesn't look like there's anything 
> particularly request-sensitive about the category tree.
> 
> Some people make lists a property of the form itself.  This is also one 
> of the core use cases for some kind of view controller registered 
> against the input forward's path, which is one of my goals to implement 
> in a Struts 1.3.x timeframe.
> 
> Joe
> 

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

Re: view controller

Posted by Joe Germuska <Jo...@Germuska.com>.

>I tell you what, don't bother about it for the moment as I have 
>unfortunately no time and it looks like I should be taking this over 
>to the dev list to carry on the discussion. If I do get time soon 
>I'll subscribe to that list.

Well, I'll bother anyway, on the off chance anyone else is following, 
and in any case, to help develop the idea further.  True enough, 
though, that this probably belongs on the dev list...

>Just from a quick look at the dev list, it seems you want to put the 
>view class as the last command on the chain. I think I must be 
>missing something.

I'm not sure what you mean by this.  As it is now, I think that in 
most cases we'd want to keep the last command on the chain as it is, 
or the last two if you're using Tiles.

org.apache.struts.chain.servlet.TilesPreProcessor
org.apache.struts.chain.servlet.PerformForward


At 7:33 PM +0000 12/2/04, Adam Hardy wrote:
>If your view controller is actually just a command on the chain for 
>an action mapping, how would you register it against the action 
>mapping's 'input' attribute in order to get pre-presentation stuff 
>to happen for the validate-failures?

One result of a failed validation is the insertion into the context 
of an ActionForward in the same place that the result of 
Action.execute is stored, so by the time you finish the "action" 
chain and begin the "view" chain, there's no difference.  (These 
sub-chains aren't defined in struts-chain now, but I think they make 
sense.)

I think you could find the view processor command by using the 
standard Chain "lookup action".  Well, out of the box, its "nameKey" 
property would depend on some String value being placed into the 
context under a certain key, and as it is now, we're talking about 
using a String property of an Object in the context under a certain 
key.  If we gave the LookupCommand an expression language (JEXL, 
perhaps?), then we could do something like this, which seems cool:

       <command
           className="org.apache.commons.chain.generic.LookupCommand"
         catalogName="struts-view-preprocess"
                nameKey="${context.forward.name}"
            optional="true"/>

or possibly work some magic to make the "context" prefix assumed. 
Anyone  have an opinion about adding a JEXL dependency to Chain, or 
whether this would be best left to a Struts subclass of LookupCommand?

But anyway, then you'd have this somewhere else:

<catalog name="struts-view-preprocess">
     <!-- ========== Servlet Complete Request Chain 
========================= -->

<command
           name="/foo/bar/Baz.jsp"
            className="com.example.webui.view.BazPrepCommand"
            formName="BazForm"
            formScope="request" />

<chain
           name="/a/b/c.jsp">
   <command className="com.example.webui.view.CPrepCommand" />
   <command className="com.example.webui.view.SomeSharedCommand" />
</chain>

<chain
           name="/a/b/d.jsp">
   <command className="com.example.webui.view.DPrepCommand" />
   <command className="com.example.webui.view.SomeSharedCommand" />
</chain>

</catalog>


>On 12/02/2004 04:05 PM Joe Germuska wrote:
>>At 10:26 AM +0000 12/2/04, Adam Hardy wrote:
>>>I'm intrigued to know how you would declare the view controllers 
>>>and register them against URLs. It would be in struts-config.xml 
>>>presumably. Would you be able to register them against a tile def? 
>>>Would the view controller have the same method signature as the 
>>>action execute()?
>>>
>>>Have you actually got anything in the nightly build yet?
>>
>>
>>No, nothing yet.  The first order of business is getting the chain 
>>in there, and action on that is waiting for the full release of 
>>Chain 1.0.  I'm thinking about the issues and looking for 
>>challenges while we wait.
>>
>>As for anything specific to a view controller -- well, I'm not sure 
>>how it would be configured, and I consider that important.  In a 
>>project here, we have a class we call "UIToolKit" which has a 
>>collection of "renderers", and then we have a "PagePrep" chain 
>>command which operates between "ExecuteAction" and 
>>"TilesPreProcess". (This allows the controllers to be registered 
>>against tiles paths, although now that I think of it, it is 
>>probably only operating for the "master" or top-level tile.
>>
>>The renderer config looks something like this:
>>
>>      <render
>>          path        =".configure.SelectTopicsOrModel"
>>          type        ="....ConfigureRenderer"
>>          method    ="selectTopicsOrModel"
>>          form        ="configure_SelectTopicsOrModel"
>>          scope   ="request"
>>          />
>>
>>where "path" is compared to the return value of "getPath()" called 
>>on the ActionForward which was returned by the Action class. 
>>"type" is a class, and "method" is a method on the class; for our 
>>local use, it is understood that the method will take a single 
>>"RenderContext" argument.  "form" and "scope" are optional, but if 
>>defined, they will be used to put a form into the RenderContext so 
>>that prepopulation can occur.  The RenderContext also has 
>>references to the request, response and other application classes 
>>which may be necessary to do the prepopulation or other view 
>>preparation.
>>
>>I'm not specifically proposing this for Struts at all, but only 
>>offering it so that people can critique and consider some of the 
>>issues we've covered here in a "prototypical" implementation of 
>>this idea.
>>
>>The RenderContext would probably be replaced by a class called 
>>"ViewContext" which has been discussed recently on the dev mailing 
>>list, and fairly thoroughly elaborated on by Ted Husted.
>>
>>Moving forward, the main question is whether it's even worth 
>>creating a new area of struts configuration for this, or whether it 
>>would be more suitable simply to advise people to configure chain 
>>commands which do the same thing.  Ted's idea is that "ViewContext" 
>>would be a subclass of Chain context, so the structure of any view 
>>controller class would be pretty similar to a Chain command: 
>>"public void execute(Context)"
>>
>>What might make more sense would be to create an abstract Chain 
>>command which knows how to look up a form and put it in the view 
>>context, and then users could extend it and implement their view 
>>preparation.  We didn't do that here because we were still very new 
>>to Chain, and we weren't yet comfortable with the chain 
>>configuration syntax.  But as this is taking shape, and as I'm 
>>writing this, I think I'm leaning towards just doing it with Chain, 
>>especially for starters.  The Chain model was recently extended to 
>>make it easier to manage a map of named command catalogs, so that 
>>you wouldn't have to cram everything into a single mega-config file.
>>
>>And, of course, something we've been noticing is that using chain, 
>>Actions themselves could be directly replaced with chain commands, 
>>once people become comfortable with chain configuration.  But one 
>>step at a time!  The initial chain implementation is totally 
>>backwards compatible with old Struts config files.


-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: view controller

Posted by Adam Hardy <ah...@cyberspaceroad.com>.

On 12/02/2004 04:05 PM Joe Germuska wrote:
> At 10:26 AM +0000 12/2/04, Adam Hardy wrote:
>> I'm intrigued to know how you would declare the view controllers and 
>> register them against URLs. It would be in struts-config.xml 
>> presumably. Would you be able to register them against a tile def? 
>> Would the view controller have the same method signature as the action 
>> execute()?
>>
>> Have you actually got anything in the nightly build yet?
> 
> 
> No, nothing yet.  The first order of business is getting the chain in 
> there, and action on that is waiting for the full release of Chain 1.0.  
> I'm thinking about the issues and looking for challenges while we wait.
> 
> As for anything specific to a view controller -- well, I'm not sure how 
> it would be configured, and I consider that important.  In a project 
> here, we have a class we call "UIToolKit" which has a collection of 
> "renderers", and then we have a "PagePrep" chain command which operates 
> between "ExecuteAction" and "TilesPreProcess". (This allows the 
> controllers to be registered against tiles paths, although now that I 
> think of it, it is probably only operating for the "master" or top-level 
> tile.
> 
> The renderer config looks something like this:
> 
>      <render
>          path        =".configure.SelectTopicsOrModel"
>          type        ="....ConfigureRenderer"
>          method    ="selectTopicsOrModel"
>          form        ="configure_SelectTopicsOrModel"
>          scope   ="request"
>          />
> 
> where "path" is compared to the return value of "getPath()" called on 
> the ActionForward which was returned by the Action class.  "type" is a 
> class, and "method" is a method on the class; for our local use, it is 
> understood that the method will take a single "RenderContext" argument.  
> "form" and "scope" are optional, but if defined, they will be used to 
> put a form into the RenderContext so that prepopulation can occur.  The 
> RenderContext also has references to the request, response and other 
> application classes which may be necessary to do the prepopulation or 
> other view preparation.
> 
> I'm not specifically proposing this for Struts at all, but only offering 
> it so that people can critique and consider some of the issues we've 
> covered here in a "prototypical" implementation of this idea.
> 
> The RenderContext would probably be replaced by a class called 
> "ViewContext" which has been discussed recently on the dev mailing list, 
> and fairly thoroughly elaborated on by Ted Husted.
> 
> Moving forward, the main question is whether it's even worth creating a 
> new area of struts configuration for this, or whether it would be more 
> suitable simply to advise people to configure chain commands which do 
> the same thing.  Ted's idea is that "ViewContext" would be a subclass of 
> Chain context, so the structure of any view controller class would be 
> pretty similar to a Chain command: "public void execute(Context)"
> 
> What might make more sense would be to create an abstract Chain command 
> which knows how to look up a form and put it in the view context, and 
> then users could extend it and implement their view preparation.  We 
> didn't do that here because we were still very new to Chain, and we 
> weren't yet comfortable with the chain configuration syntax.  But as 
> this is taking shape, and as I'm writing this, I think I'm leaning 
> towards just doing it with Chain, especially for starters.  The Chain 
> model was recently extended to make it easier to manage a map of named 
> command catalogs, so that you wouldn't have to cram everything into a 
> single mega-config file.
> 
> And, of course, something we've been noticing is that using chain, 
> Actions themselves could be directly replaced with chain commands, once 
> people become comfortable with chain configuration.  But one step at a 
> time!  The initial chain implementation is totally backwards compatible 
> with old Struts config files.

If your view controller is actually just a command on the chain for an 
action mapping, how would you register it against the action mapping's 
'input' attribute in order to get pre-presentation stuff to happen for 
the validate-failures?

Just from a quick look at the dev list, it seems you want to put the 
view class as the last command on the chain. I think I must be missing 
something.

I tell you what, don't bother about it for the moment as I have 
unfortunately no time and it looks like I should be taking this over to 
the dev list to carry on the discussion. If I do get time soon I'll 
subscribe to that list.

Thanks
Adam


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

Re: view controller

Posted by Joe Germuska <Jo...@Germuska.com>.

At 10:26 AM +0000 12/2/04, Adam Hardy wrote:
>
>OK, I understand now. :)
>
>I'm intrigued to know how you would declare the view controllers and 
>register them against URLs. It would be in struts-config.xml 
>presumably. Would you be able to register them against a tile def? 
>Would the view controller have the same method signature as the 
>action execute()?
>
>Have you actually got anything in the nightly build yet?

No, nothing yet.  The first order of business is getting the chain in 
there, and action on that is waiting for the full release of Chain 
1.0.  I'm thinking about the issues and looking for challenges while 
we wait.

As for anything specific to a view controller -- well, I'm not sure 
how it would be configured, and I consider that important.  In a 
project here, we have a class we call "UIToolKit" which has a 
collection of "renderers", and then we have a "PagePrep" chain 
command which operates between "ExecuteAction" and "TilesPreProcess". 
(This allows the controllers to be registered against tiles paths, 
although now that I think of it, it is probably only operating for 
the "master" or top-level tile.

The renderer config looks something like this:

	 <render
		 path		=".configure.SelectTopicsOrModel"
		 type		="....ConfigureRenderer"
		 method	="selectTopicsOrModel"
		 form		="configure_SelectTopicsOrModel"
		 scope   ="request"
		 />

where "path" is compared to the return value of "getPath()" called on 
the ActionForward which was returned by the Action class.  "type" is 
a class, and "method" is a method on the class; for our local use, it 
is understood that the method will take a single "RenderContext" 
argument.  "form" and "scope" are optional, but if defined, they will 
be used to put a form into the RenderContext so that prepopulation 
can occur.  The RenderContext also has references to the request, 
response and other application classes which may be necessary to do 
the prepopulation or other view preparation.

I'm not specifically proposing this for Struts at all, but only 
offering it so that people can critique and consider some of the 
issues we've covered here in a "prototypical" implementation of this 
idea.

The RenderContext would probably be replaced by a class called 
"ViewContext" which has been discussed recently on the dev mailing 
list, and fairly thoroughly elaborated on by Ted Husted.

Moving forward, the main question is whether it's even worth creating 
a new area of struts configuration for this, or whether it would be 
more suitable simply to advise people to configure chain commands 
which do the same thing.  Ted's idea is that "ViewContext" would be a 
subclass of Chain context, so the structure of any view controller 
class would be pretty similar to a Chain command: "public void 
execute(Context)"

What might make more sense would be to create an abstract Chain 
command which knows how to look up a form and put it in the view 
context, and then users could extend it and implement their view 
preparation.  We didn't do that here because we were still very new 
to Chain, and we weren't yet comfortable with the chain configuration 
syntax.  But as this is taking shape, and as I'm writing this, I 
think I'm leaning towards just doing it with Chain, especially for 
starters.  The Chain model was recently extended to make it easier to 
manage a map of named command catalogs, so that you wouldn't have to 
cram everything into a single mega-config file.

And, of course, something we've been noticing is that using chain, 
Actions themselves could be directly replaced with chain commands, 
once people become comfortable with chain configuration.  But one 
step at a time!  The initial chain implementation is totally 
backwards compatible with old Struts config files.

Joe

On 12/01/2004 02:37 PM Joe Germuska wrote:
>>Yes but only half. Regarding the first point, since struts is 
>>actually able to accept and deal with a second action mapping in 
>>that mapping's "input" (or "forward") param, then somehow struts 
>>must be designed for it. It can't possibly have been a happy 
>>coincidence, surely? I don't know about tests.
>
>
>Not really; it's just a side effect.  Struts is merely calling 
>requestDispatcher.forward(...)    If Struts were designed for it, 
>you wouldn't be including the ".do" in the value of input, in the 
>same way in which you don't have to include it in the "action" 
>attribute of an html:form tag.
>
>To say that Struts isn't "tested" for it may be overplaying the kind 
>of testing we have, but it is true that in general, action chaining 
>is considered "unsupported."  As you'll see below, deeper changes 
>underway in Struts should obsolete the need to chain using multiple 
>calls to requestDispatcher.forward(...) (with repeated runs through 
>the entire request processing cycle).  The whole request processing 
>cycle is going to be much more open and flexible.
>
>>I appreciate your direction though. Do you envisage being in a 
>>position to completely disable chaining in struts? Let me describe 
>>the situation I had at my last project where it was useful (and 
>>justified IMHO):
>>
>>The screens were complex and were not under my control. Each screen 
>>contained up to 3 completely seperate bits of functionality, e.g. 
>>hotel bank account number, hotel billing address and hotel billing 
>>options. These were handled by different session facade calls.
>>
>>I had already experienced alot of scope creep and I knew that these 
>>would change, and in fact I was pushing to get control of the 
>>screen designs, in which case I would simply have put the 3 
>>different bits on different screens - so when coding the mappings, 
>>I made 3 mappings and chained them together, so I could seperate 
>>out the Action classes and hopefully actually seperate out the page 
>>too in the future.
>>
>>I didn't get the opportunity to seperate out the pages, but I was 
>>still happy that I could chain the mappings and have seperate 
>>Action classes.
>
>
>I think that this is a good use case for the commons-chain library, 
>and probably for the "ChainAction" that Craig recently wrote.  The 
>ChainAction is meant as a way for users to delegate Action 
>processing to a commons-chain command (which itself may be a chain 
>of commands) in a way that would have allowed you to rearrange the 
>"plumbing" just by editing config files.  Using these things right 
>now is still a little cutting-edge, as there is still a lot of 
>documentation to write, and probably some better support for 
>multiple chain-configuration files...  we're hoping to push these 
>things into the Struts core CVS as soon as commons-chain makes its 
>1.0 release (any day now).
>
>Strictly speaking, this is all kind of tangential to a view 
>controller, and in fact, if you were using ChainAction, you could 
>slot in commands that each had any balance of responsibilities 
>between "action processing" and "view preparation" that you liked. 
>We might find ourselves looking for some good ways to standardize 
>things like instantiation or location of the form bean which might 
>need to be prepopulated for the destination view, which is one of 
>the reasons I like the idea of formalizing view preparation.
>
>Joe
>

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: view controller

Posted by Adam Hardy <ah...@cyberspaceroad.com>.

On 12/01/2004 02:37 PM Joe Germuska wrote:
>> Yes but only half. Regarding the first point, since struts is actually 
>> able to accept and deal with a second action mapping in that mapping's 
>> "input" (or "forward") param, then somehow struts must be designed for 
>> it. It can't possibly have been a happy coincidence, surely? I don't 
>> know about tests.
> 
> 
> Not really; it's just a side effect.  Struts is merely calling 
> requestDispatcher.forward(...)    If Struts were designed for it, you 
> wouldn't be including the ".do" in the value of input, in the same way 
> in which you don't have to include it in the "action" attribute of an 
> html:form tag.
> 
> To say that Struts isn't "tested" for it may be overplaying the kind of 
> testing we have, but it is true that in general, action chaining is 
> considered "unsupported."  As you'll see below, deeper changes underway 
> in Struts should obsolete the need to chain using multiple calls to 
> requestDispatcher.forward(...) (with repeated runs through the entire 
> request processing cycle).  The whole request processing cycle is going 
> to be much more open and flexible.
> 
>> I appreciate your direction though. Do you envisage being in a 
>> position to completely disable chaining in struts? Let me describe the 
>> situation I had at my last project where it was useful (and justified 
>> IMHO):
>>
>> The screens were complex and were not under my control. Each screen 
>> contained up to 3 completely seperate bits of functionality, e.g. 
>> hotel bank account number, hotel billing address and hotel billing 
>> options. These were handled by different session facade calls.
>>
>> I had already experienced alot of scope creep and I knew that these 
>> would change, and in fact I was pushing to get control of the screen 
>> designs, in which case I would simply have put the 3 different bits on 
>> different screens - so when coding the mappings, I made 3 mappings and 
>> chained them together, so I could seperate out the Action classes and 
>> hopefully actually seperate out the page too in the future.
>>
>> I didn't get the opportunity to seperate out the pages, but I was 
>> still happy that I could chain the mappings and have seperate Action 
>> classes.
> 
> 
> I think that this is a good use case for the commons-chain library, and 
> probably for the "ChainAction" that Craig recently wrote.  The 
> ChainAction is meant as a way for users to delegate Action processing to 
> a commons-chain command (which itself may be a chain of commands) in a 
> way that would have allowed you to rearrange the "plumbing" just by 
> editing config files.  Using these things right now is still a little 
> cutting-edge, as there is still a lot of documentation to write, and 
> probably some better support for multiple chain-configuration files...  
> we're hoping to push these things into the Struts core CVS as soon as 
> commons-chain makes its 1.0 release (any day now).
> 
> Strictly speaking, this is all kind of tangential to a view controller, 
> and in fact, if you were using ChainAction, you could slot in commands 
> that each had any balance of responsibilities between "action 
> processing" and "view preparation" that you liked. We might find 
> ourselves looking for some good ways to standardize things like 
> instantiation or location of the form bean which might need to be 
> prepopulated for the destination view, which is one of the reasons I 
> like the idea of formalizing view preparation.
> 
> Joe
> 

OK, I understand now. :)

I'm intrigued to know how you would declare the view controllers and 
register them against URLs. It would be in struts-config.xml presumably. 
Would you be able to register them against a tile def? Would the view 
controller have the same method signature as the action execute()?

Have you actually got anything in the nightly build yet?

Rgds
Adam


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

Re: view controller

Posted by Joe Germuska <Jo...@Germuska.com>.

>Yes but only half. Regarding the first point, since struts is 
>actually able to accept and deal with a second action mapping in 
>that mapping's "input" (or "forward") param, then somehow struts 
>must be designed for it. It can't possibly have been a happy 
>coincidence, surely? I don't know about tests.

Not really; it's just a side effect.  Struts is merely calling 
requestDispatcher.forward(...)    If Struts were designed for it, you 
wouldn't be including the ".do" in the value of input, in the same 
way in which you don't have to include it in the "action" attribute 
of an html:form tag.

To say that Struts isn't "tested" for it may be overplaying the kind 
of testing we have, but it is true that in general, action chaining 
is considered "unsupported."  As you'll see below, deeper changes 
underway in Struts should obsolete the need to chain using multiple 
calls to requestDispatcher.forward(...) (with repeated runs through 
the entire request processing cycle).  The whole request processing 
cycle is going to be much more open and flexible.

>I appreciate your direction though. Do you envisage being in a 
>position to completely disable chaining in struts? Let me describe 
>the situation I had at my last project where it was useful (and 
>justified IMHO):
>
>The screens were complex and were not under my control. Each screen 
>contained up to 3 completely seperate bits of functionality, e.g. 
>hotel bank account number, hotel billing address and hotel billing 
>options. These were handled by different session facade calls.
>
>I had already experienced alot of scope creep and I knew that these 
>would change, and in fact I was pushing to get control of the screen 
>designs, in which case I would simply have put the 3 different bits 
>on different screens - so when coding the mappings, I made 3 
>mappings and chained them together, so I could seperate out the 
>Action classes and hopefully actually seperate out the page too in 
>the future.
>
>I didn't get the opportunity to seperate out the pages, but I was 
>still happy that I could chain the mappings and have seperate Action 
>classes.

I think that this is a good use case for the commons-chain library, 
and probably for the "ChainAction" that Craig recently wrote.  The 
ChainAction is meant as a way for users to delegate Action processing 
to a commons-chain command (which itself may be a chain of commands) 
in a way that would have allowed you to rearrange the "plumbing" just 
by editing config files.  Using these things right now is still a 
little cutting-edge, as there is still a lot of documentation to 
write, and probably some better support for multiple 
chain-configuration files...  we're hoping to push these things into 
the Struts core CVS as soon as commons-chain makes its 1.0 release 
(any day now).

Strictly speaking, this is all kind of tangential to a view 
controller, and in fact, if you were using ChainAction, you could 
slot in commands that each had any balance of responsibilities 
between "action processing" and "view preparation" that you liked. 
We might find ourselves looking for some good ways to standardize 
things like instantiation or location of the form bean which might 
need to be prepopulated for the destination view, which is one of the 
reasons I like the idea of formalizing view preparation.

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: view controller

Posted by Adam Hardy <ah...@cyberspaceroad.com>.

On 11/28/2004 04:40 PM Joe Germuska wrote:
> At 11:31 AM +0000 11/24/04, Adam Hardy wrote:
>> On 11/23/2004 02:20 PM Joe Germuska wrote:
>>
>>> Your action isn't executed if validation fails.  However, the 
>>> validation is performed on a second request, so the object placed 
>>> into the scope before the form was presented is no longer there.
>>>
>>> If your categories are really relatively static, consider managing 
>>> them in Application scope rather than request.  I often have one or 
>>> more plugins which initialize common menus like states and provinces 
>>> or months of the year and place them into the application scope (I 
>>> like to use the DigestingPlugIn).  Your code doesn't look like 
>>> there's anything particularly request-sensitive about the category tree.
>>>
>>> Some people make lists a property of the form itself.  This is also 
>>> one of the core use cases for some kind of view controller registered 
>>> against the input forward's path, which is one of my goals to 
>>> implement in a Struts 1.3.x timeframe.
>>>
>>> Joe
>>
>>
>> Joe,
>>
>> I hope you don't think I'm labouring a point after the big discussion 
>> last week, but regarding a view controller registered against the 
>> input forward's path, I just don't get the paradigm.
>>
>> It seems like an unnecessary complexity when you can do what Matt 
>> suggested and point the input attribute at a 'loader' action mapping.
> 
> 
> As Struts is designed now, setting the "input" attribute of an action 
> mapping to point to another action mapping results in two passes through 
> the request processor for a single HTTP request.  This is not a use case 
> for which Struts is designed or tested, and which could have strange 
> side effects.  Certainly, many people use it today without problems, but 
> why not move Struts towards a clearly defined usage pattern which 
> doesn't involve any grey areas like this?
> 
>> Having a loader action decouples it from the validation+processing 
>> action, which seems friendly and OO to me. Then you can use that 
>> loader action from anywhere - can you say the same about your view 
>> controller registered against the input forward path?
> 
> 
> When I say that it's registered against the input forward path, I don't 
> mean that it's connected to the validating action mapping.  I mean that 
> the system is configured so that any time it is headed to the path 
> defined as the input forward path, it will execute one or more view 
> controllers.  Therefore, it doesn't matter whether you are presenting 
> the form for the first time or on a subsequent pass; the view controller 
> code would still be executed.  To me this seems "more OO" because it 
> associates the processing code with the context in which it is used.  No 
> one needs to remember a sequence of actions which must be chained; they 
> just trust that the request context (including the session and 
> application) have the right data in the right places, and then small 
> adjustments necessary to rendering the view can be encapsulated cleanly.
> 
> Does that help at all?
> 
> Joe

Yes but only half. Regarding the first point, since struts is actually 
able to accept and deal with a second action mapping in that mapping's 
"input" (or "forward") param, then somehow struts must be designed for 
it. It can't possibly have been a happy coincidence, surely? I don't 
know about tests.

I appreciate your direction though. Do you envisage being in a position 
to completely disable chaining in struts? Let me describe the situation 
I had at my last project where it was useful (and justified IMHO):

The screens were complex and were not under my control. Each screen 
contained up to 3 completely seperate bits of functionality, e.g. hotel 
bank account number, hotel billing address and hotel billing options. 
These were handled by different session facade calls.

I had already experienced alot of scope creep and I knew that these 
would change, and in fact I was pushing to get control of the screen 
designs, in which case I would simply have put the 3 different bits on 
different screens - so when coding the mappings, I made 3 mappings and 
chained them together, so I could seperate out the Action classes and 
hopefully actually seperate out the page too in the future.

I didn't get the opportunity to seperate out the pages, but I was still 
happy that I could chain the mappings and have seperate Action classes.

Do you see what I mean?


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