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/21 06:09:50 UTC
[shale][struts-faces] structured URLs with JSF (reprised)
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?
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 "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
>
>
Re: [OT] customizing JSF view management (was [shale][struts-faces]
structured URLs with JSF (reprised))
Posted by Laurie Harper <la...@holoweb.net>.
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: [shale][struts-faces] structured URLs with JSF (reprised)
Posted by "David G. Friedman" <hu...@ix.netcom.com>.
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: [shale][struts-faces] structured URLs with JSF (reprised)
Posted by Laurie Harper <la...@holoweb.net>.
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
Re: [shale][struts-faces] structured URLs with JSF (reprised)
Posted by Laurie Harper <la...@holoweb.net>.
Craig McClanahan wrote:
> On 12/21/05, Laurie Harper <la...@holoweb.net> wrote:
>> The context relative thing is not the behaviour I'm seeing though. If I
>> have a navigation rule that points to /foo/bar.jsp with redirect set,
>> the browser is redirected to /faces/foo/bar.jsp.
>
> That would imply you have FacesServlet mapped to "/faces/*", right? This is
> indeed the URL that the submit would have to go to. If you map FacesServlet
> to "*.faces" instead, the emitted URl would be "/foo/bar.faces" instead.
Right, which still wouldn't give me what I was shooting for -- having
the to-view-id URL served by a different servlet. The original idea was
to have /faces/* mapped to the Faces servlet but route requests through
a separate servlet, say /view/*, which would know how to map logical
URLs to physical views and forward [I didn't describe that scheme in
this thread, though :-)].
I'm sold on the general principle that this isn't such a great idea, but
I'm still not sure I can get what I want any other way. I can use a
custom navigation handler to change the way to-view-id is handled,
though. I just can't see how to use one to avoid the seperate controller
servlet altogether (see following post).
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [shale][struts-faces] structured URLs with JSF (reprised)
Posted by Craig McClanahan <cr...@apache.org>.
On 12/21/05, Laurie Harper <la...@holoweb.net> wrote:
>
> 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 '/'.)
>
> Hmm, I'll have to take another look at navigation handlers then. I'll
> have to experiment a bit.
>
> The context relative thing is not the behaviour I'm seeing though. If I
> have a navigation rule that points to /foo/bar.jsp with redirect set,
> the browser is redirected to /faces/foo/bar.jsp.
That would imply you have FacesServlet mapped to "/faces/*", right? This is
indeed the URL that the submit would have to go to. If you map FacesServlet
to "*.faces" instead, the emitted URl would be "/foo/bar.faces" instead.
Maybe I can get what I
> was shooting for if I switch to suffix mapping for the Faces servlet?
> Though based on your comments on the MyFaces list, I tend to agree that
> the servlet approach I wanted this for is probably not the best idea...
That would be worth a try (see above).
> One consequence of that decision, however, is that you can't pass
> > information in request scope from one page to another (because the
> rendering
> > is done in a separate HTTP request). Here is where Shale's view handler
> > capabilities can come in handy, however ... if you have such a backing
> bean
> > for each JSP page, it's prerender() method will be invoked immediately
> > before the page is rendered. As such, it is pretty much analogous to a
> > "setup" action in Struts 1.x based applications, and you can use it to
> go
> > collect any model data needed to render this page.
>
> Yep, that's broadly what I was intending on doing.
>
> Thanks,
>
> L.
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: [shale][struts-faces] structured URLs with JSF (reprised)
Posted by Laurie Harper <la...@holoweb.net>.
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 '/'.)
Hmm, I'll have to take another look at navigation handlers then. I'll
have to experiment a bit.
The context relative thing is not the behaviour I'm seeing though. If I
have a navigation rule that points to /foo/bar.jsp with redirect set,
the browser is redirected to /faces/foo/bar.jsp. Maybe I can get what I
was shooting for if I switch to suffix mapping for the Faces servlet?
Though based on your comments on the MyFaces list, I tend to agree that
the servlet approach I wanted this for is probably not the best idea...
> One consequence of that decision, however, is that you can't pass
> information in request scope from one page to another (because the rendering
> is done in a separate HTTP request). Here is where Shale's view handler
> capabilities can come in handy, however ... if you have such a backing bean
> for each JSP page, it's prerender() method will be invoked immediately
> before the page is rendered. As such, it is pretty much analogous to a
> "setup" action in Struts 1.x based applications, and you can use it to go
> collect any model data needed to render this page.
Yep, that's broadly what I was intending on doing.
Thanks,
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [shale][struts-faces] structured URLs with JSF (reprised)
Posted by Craig McClanahan <cr...@apache.org>.
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 '/'.)
One consequence of that decision, however, is that you can't pass
information in request scope from one page to another (because the rendering
is done in a separate HTTP request). Here is where Shale's view handler
capabilities can come in handy, however ... if you have such a backing bean
for each JSP page, it's prerender() method will be invoked immediately
before the page is rendered. As such, it is pretty much analogous to a
"setup" action in Struts 1.x based applications, and you can use it to go
collect any model data needed to render this page.
L.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>