You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Laurie Harper <la...@holoweb.net> on 2005/12/23 05:56:49 UTC
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:news@sea.gmane.org]On 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 <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised))
Posted by "David G. Friedman" <hu...@ix.netcom.com>.
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:news@sea.gmane.org]On 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 <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] customizing JSF view management (was [shale][struts-faces]
structured URLs with JSF (reprised))
Posted by Laurie Harper <la...@holoweb.net>.
Craig McClanahan wrote:
> On 12/22/05, Laurie Harper <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] customizing JSF view management (was [shale][struts-faces] structured URLs with JSF (reprised))
Posted by Craig McClanahan <cr...@apache.org>.
On 12/22/05, Laurie Harper <la...@holoweb.net> 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:news@sea.gmane.org]On 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 <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>