Re: page validation

I just spotted another weakness of Mindbridge's scheme. Page validation is 
"chained" when going through the activate route. In other words, if the 
first page fails validation, the redirect page will still have to pass 
validation and have an opportunity to redirect once again, ad inf. However, 
as has been pointed out before, the default validation check performed by 
the page services will *not* chain. After validating the first redirect 
page, no more validation takes place.

So I think for Mindbridge's scheme to work well, the page services will have 
to call activate() rather than setPage(), which implies putting activate() 
on IPage.

comments?

Joseph Panico
[email protected]




>From: "Joseph Panico" <[email protected]>
>To: [email protected]
>Subject: [Tapestry-developer] page validation
>Date: Fri, 10 Jan 2003 15:26:20 +0000
>
>Yep, the old horse of page validation is still alive!
>
>Last year there was a lot of discussion about fixing IPage.validate(). But 
>I'm not sure we ever firmly arrived at a consensus solution, and it appears 
>that validate() still works the same way in 2.3. So I would like to try to 
>stimulate an improvement for 2.4.
>
>In summary: IPage.validate() is automatically called by any of the page 
>oriented services (Direct, Action, Page, External, Home, Reset). So when 
>Tapestry is handling the page navigation for you, at this high level, you 
>are guaranteed to have your method invoked. However, it's quite common for 
>developers to come up with more sophisticated navigation schemes that 
>require effecting page transitions with calls to cycle.setPage(), which 
>bypasses the validation mechanism. So there is a "mismatch"-- sometimes 
>validate() gets called and sometimes it doesn't. Worse still, tapestry 
>newbies are unlikely to realize this and wonder why their validation 
>schemes don't work (which is what happened to me originally).
>
>I know that a *lot* of people have encountered this problem and rolled 
>their own solutions. Can we come up with a consensus for how it should work 
>and then get the new design in 2.4?
>
>Mindbridge had a very sensible sounding suggestion, namely:
>
>One approach to resolve these issues that we use here locally is to add the 
>method
>activate() to the pages and invoke it instead of calling setPage():
>
>page.activate(cycle);
>
>A possible implementation could be something like this:
>
>public void activate(IRequestCycle cycle) throws RequestCycleException
>{
>   try {
>     this.validate(cycle);
>     cycle.setPage(this);
>   }
>   catch (PageRedirectException e) {
>     IPage page = cycle.getPage(e.getTargetPageName());
>     page.activate(cycle);
>   }
>}
>
>This looks like a pretty good solution, and I'm using it now. The only 
>weakness I can see is that activate() will not get called by the page 
>oriented services, and so if you rely on activate for something other than 
>validation (via overriding, let's say), you are hosed. One solution to that 
>problem would be to modify the implementations of the page services to use 
>activate().
>
>thoughts?
>
>Joseph Panico
>[email protected]
>
>
>
>_________________________________________________________________
>Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* 
>http://join.msn.com/?page=features/junkmail
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Tapestry-developer mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/tapestry-developer


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com