You can get it from the HttpServletRequest object. <bean:page id="req" property="request"/>
Here's the javadoc page: http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/http/HttpServletRequest. html Daniel > -----Original Message----- > From: Garner, Shawn [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 27, 2005 1:27 PM > To: 'Struts Users Mailing List' > Subject: RE: [OT] customizing JSF view management (was > [shale][struts-faces] structured URLs with JSF (reprised)) > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
