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]
>
>
