Is there a way to get the view as in the name of the jsp page within the code?
Shawn -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Thursday, December 22, 2005 11:24 PM To: Struts Users Mailing List Subject: Re: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised)) 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. L. Craig David G. Friedman wrote: > > I'm trying to do something similar with a lifecycle. My goal is to > virtual host but retain the viewId of /about.jsf > > while building off the main file /somehostname/about.jsf. > > > > Here's what I have done so far, added a lifecycleFactory to my > faces-config.xml file. My own factory's init method is > > the only thing I changed. I added my own lifecycle class using the name > "VIRTUALHOST" then set the web.xml param > > javax.faces.LIFECYCLE_ID to use the name "VIRTUALHOST" instead of the > default lifecycle object which gets loaded in the > > name "DEFAULT" > > > > It's complicated and slow going since I'm working on it on my own time > but I hope this information helps. > > > > Regards, > > David > > > > -----Original Message----- > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Laurie Harper > > Sent: Wednesday, December 21, 2005 9:31 PM > > To: user@struts.apache.org > > Subject: Re: [shale][struts-faces] structured URLs with JSF (reprised) > > > > > > Craig McClanahan wrote: > >> On 12/20/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > >>> So I'm pretty much sold on migrating from Struts/JSPs to JSF at this > >>> point, with one remaining caveat I've yet to figure out. I've brought > >>> this up before, but haven't found a good solution yet. I think the > >>> easiest way to get what I want is to use struts-faces, but then I > can't > >>> get the benefits of Shale... So, I'd like to revisit the base > >>> requirements to see if anyone can see a way to do what I want w/out > >>> Struts Action / struts-faces in the mix... > >>> > >>> My base requirement is that everything be directly addressable by a > >>> bookmark-able URL. So, for example, I'd like to have a URL like > >>> http://.../users to be rendered by /users.jsp as a list of users and, > >>> when you click on an entry in the list, you'd get taken to > >>> http://.../users/bob which would be rendered by /userInfo.jsp. For any > >>> X, the URL http://.../users/X would be rendered by /userInfo.jsp, with > X > >>> being made available to the JSP (or backing bean) as a request > >>> parameter, request attribute or whatever. > >>> > >>> Using struts-faces, I can get what I want by using wild-card action > >>> mappings to map logical URLs to physical JSPs, passing wild-card > matched > >>> parts of the request URL on to the view in the action; something like, > >>> roughly: > >>> > >>> <action path="/users/*" type="myaction" forward="/user.jsp"> > >>> <set-property name="user" value="{1}"/> > >>> > >>> I need a way to get the same mapping from logical URLs to actual JSPs > >>> with vanilla JSF / Shale. Sean suggested I could try writing a custom > >>> navigation handler, but that doesn't seem to work since a navigation > >>> handler only gets to influence how from-view-id/from-outcome pairs get > >>> mapped to views. > >>> > >>> I tried setting up a front controller servlet that encapsulates the > >>> URL-to-view mapping logic, but that doesn't work because to-view-id in > a > >>> navigation-rule is not a context relative path, so my navigation rules > >>> can't route through my controller servlet... > >>> > >>> I'm really hoping I can find a way to do this that doesn't involve > >>> deploying Struts + struts-faces as a front controller to Shale ;-) My > >>> requirements can't be *that* weird can they? > >> > >> No, you just need a custom NavigationHandler, coupled with using > <redirect/> > >> elements in your navigation rules to ensure that the URLs in the > browser are > >> what you are after. (See also my response to your comment on the > myfaces > >> list too ... view identifiers for the default view handler *are* > context > >> relative paths starting with a '/'.) > > > > So I figured out how to install a custom navigation handler, and gave > > this a try but when I make a request to a particular URL the navigation > > handler isn't called. It only gets called when I click on a command link > > or other navigation element in a rendered view. > > > > What I need is to completely decouple the URL the browser requests from > > the JSP that gets rendered as a result, to provide a less direct mapping > > from the one to the other. > > > > Is there something I'm missing about the navigation handler approach? Is > > there some way to get it to be invoked on an initial request? > > > > Thanks, > > > > 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] > > **************************************************************************** This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. **************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
