RE: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised))
You might take a look at the Shale Clay view handler if you are trying to override the generated viewid. http://svn.apache.org/viewcvs.cgi/struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/faces/ClayViewHandler.java?view=markup I found some strange inconsistencies in the behavior of the view handler between Sun's RI and MyFaces. Myfaces is very picky about the view id. It will rename the suffix to match the javax.faces.DEFAULT_SUFFIX init param in the web.xml. The Sun RI seems to be OK with any URL matching a servlet mapping. Your request URL will depend on how you have the faces servlet mapped and if it's a GET or POST request. The "getActionURL" method of the view handler is what the form component uses to populate the action attribute in the html form element. Gary -- Original message -- From: "Daniel Blumenthal" <[EMAIL PROTECTED]> > You can get it from the HttpServletRequest object. > > > > 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 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"
RE: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised))
You can get it from the HttpServletRequest object. 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 St
RE: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised))
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]
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]
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: > >>> > >>> > >>> > >>> > >>> 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 > > >> 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
Re: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised))
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 :-) L. 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: 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 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. - T