On 12/21/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > 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 '/'.) > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
