I've also been thinking about the ViewHandler approach for a day or two but haven't tried anything with that yet. Your code is much simpler than what I'd been daydreaming/pondering in between other tasks today.
Regards, David -----Original Message----- From: news [mailto:[EMAIL PROTECTED] Behalf Of Laurie Harper Sent: Friday, December 23, 2005 12:59 AM To: user@struts.apache.org Subject: Re: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised)) Craig McClanahan wrote: > On 12/22/05, Laurie Harper <[EMAIL PROTECTED]> wrote: >> I think I've found an easier way... It looks like both our needs can be >> met by installing a custom ViewHandler that just delegates all methods >> to its parent, but which changes the viewId passed into createView >> before calling super.createView: >> >> public class ProjectivaViewHandler extends ViewHandler { >> private ViewHandler parent; >> >> public ProjectivaViewHandler(ViewHandler parent) { >> this.parent = parent; >> } >> >> public UIViewRoot createView(FacesContext ctx, String viewId) { >> String pathToActualView = myViewLogic(viewId); >> return super.createView(ctx, pathToActualView); >> } >> >> ... >> } >> >> In my case I'd also need to push data from the original viewId into the >> request for use during rendering and use a custom NavigationHandler to >> let me carry parts of the from-view-id into the to-view-id, but I don't >> think you'd need that: just calling createView(ctx, "/somehost" + >> viewId) would be sufficient for you. >> >> Craig, does this sound like a reasonable thing to be doing? It sure >> *looks* like a solution to the problem :-) > > > The view that ultimately gets created will have a view identifier (as > returned by getFacesContext().getViewRoot().getViewId()) of the *actual* > view that was created, not the identifier you passed in from the navigation > rule. As long as that's OK with your business logic, it sounds like you > might have a reasonable solution. Meaning that getFacesContext().getViewRoot().getViewId() will return what I pass into super.createView (pathToActualView), not what was passed into createView originally (viewId)? To be honest, I don't know JSF well enough yet to understand the consequences of that. I don't have anything yet which depends on or calls that method, so I suspect it's OK... I've just implemented what I described above and it certainly seem to be working for me so far; i still have to figure out how to write a NavigationHandler that cooperates with this scheme, though. Sounds like I'm on the right track, I'll see how it goes tomorrow with writing a nav handler that closes the loop. L. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
