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
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer

Reply via email to