Yes, I reaaalllyyy want that as well.
Matze has already suggested that - we'll have that in our solution ;)
regards,
Martin
On 1/27/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> And once you'd solved this what you'd *really* want on top of this is
> something in the nav handler that lets you then also deal with the
> incoming "id" query attribute that feeds naturally back into JSF component
> state land instead of forcing you to hardcode logic to implement this.
> (Seam Conversations and ADF processScope come to mind.)
>
> -- Adam
>
>
> On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > That's an interesting solution-- with webwork, it allows EL (OGNL)
> > evaluation of URIs, so across the board, we could do something like:
> >
> > <navigation-rule>
> > <from-view-id>/foo.jsp</from-view-id>
> > <navigation-case>
> > <from-outcome>success</from-outcome>
> > <redirect/>
> > <to-view-id>/user.jsf?id=#{user.id}</to-view-id>
> > </navigation-case>
> > </navigation-rule>
> >
> > Where we could now say that the resulting view-id is evaluated as an
> > expression based on the current state of the FacesContext.
> >
> > -- Jacob
> >
> > >
> > >My idea's always been something like an optional
> > >NavigationHandler interface:
> > >
> > >public interface BookmarkableNavigationHandler
> > >{
> > > /**
> > > * Return an URL if the MethodExpression can be handled purely
> > > * as a GET request, or null if it cannot be done.
> > > */
> > > public String getUrl(FacesContext, MethodExpression)
> > >}
> > >
> > >This would enable a NavigationHandler to turn constant MethodExpressions,
> > >like action="foo", into simple GET URLs. (The optional interface idea
> > >does run into serious problems with any decorating NavigationHandlers;
> > >ADF Faces uses a "Service" API kinda like the old MS OLE IUnknown
> > >QueryInterface approach, if you've had the misfortune of developing
> > >any OLE code in your career).
> > >
> > >It'd also allow a more sophisticated NavigationHandler to provide metadata
> > >that says that for a specific page, a more complicated action:
> > > action="#{row.showRow}"
> > >... could perhaps be handled as a GET too:
> > >
> > > <from-view-id>myTable.jspx</from-view-id>
> > > <action>#{row.showRow}
> > > <get-url>/faces/showRow.jspx?id=#{row.id}</get-url>
> > > </from-view-id>
> > >
> > >... without any change in the page semantics. This sort of approach
> > >also lets an application's architect change up requirements, like
> > >perhaps deciding that specific
> > >app really does need to use postback for all requests, for funkier
> > >requirements
> > >like saving temporarily entered results. And you could do so without
> > >forcing users to change back from outputLink to commandLink.
> > >
> > >-- Adam
> > >
> > >On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >> I don't think the problem should be solved.
> > >>
> > >> No one says that all of your commandLinks need to invoke actions-- you
> > >> can
> > >render normal links. With invoking actions, you posting transitional
> > >behavior, with gets, there is not transitional behavior to retain. When
> > >you
> > >want to bookmark things, that designates the URI as repeatable, which is a
> > >far
> > >separation from the intentions of JSF's action/stateful capabilities.
> > >>
> > >> Nothing is stopping someone from using JSF to render a table that prints
> > >> out
> > >normal links like: <a href="/person.jsf?id=533">Click</a> and use RESTful
> > >principles for actually rendering that page based on Ed's/EG's 1)
> > >ManagedBean
> > >Create/Destroy annotations and 2) Attaching listeners to the UIViewRoot
> > >>
> > >> I (personally) think this issue shouldn't be solved since it breaks POST
> > >> vs.
> > >GET and would assert transitional behavior where it shouldn't be.
> > >>
> > >> -- Jacob
> > >>
> > >> >
> > >> >Gruß Gott,
> > >> >
> > >> >>>>>> On Fri, 27 Jan 2006 10:43:23 +0100, Werner Punz <[EMAIL
> > >> >>>>>> PROTECTED]> said:
> > >> >
> > >> >WP> +1000 for a get....
> > >> >WP> Martin Marinschek schrieb:
> > >> >
> > >> >MM> I'm having ideas again. Must come from too much work with JSF ;)
> > >> >MM>
> > >> >MM> My idea:
> > >> >MM>
> > >> >MM> Bookmarking is a problem with JSF, right? Except you use
> > >> >h:outputLink,
> > >> >MM> but then there's this slight problem with not being in the action
> > >> >MM> system anymore ;)
> > >> >MM>
> > >> >MM> Now, what do I want to be able to see in my history or to bookmark?
> > >> >I
> > >> >MM> want to bookmark simple pages, where state is not so important at
> > >> >all.
> > >> >MM> Or only a small portion of the state is important...
> > >> >MM>
> > >> >MM> Those simple pages I usually refer to with an "action" attribute
> > >> >that
> > >> >MM> is put (as a string) directly on the <h:commandLink /> or
> > >> >MM> <h:commandButton/> tag, right?
> > >> >MM>
> > >> >MM> Why not render out this action attribute as a parameter to the URL
> > >> >of
> > >> >MM> the link optionally, not submitting a form and loosing all JSF
> > >> >state,
> > >> >MM> but having a bookmarkable link?
> > >> >MM>
> > >> >MM> The developer can decide then:
> > >> >MM> - do I need this link to be bookmarked
> > >> >MM> - do I want this link to use the plain old JSF posting system with
> > >> >MM> state-saving.
> > >> >
> > >> >Right, I've thought about this problem for the Sun impl, and we even
> > >> >have an issue on our issue tracker for it:
> > >> >
> > >> >https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=72
> > >> >
> > >> >MM> Enhancement: we could additionally render out params to this link
> > >> >as -
> > >> >MM> yes, right, params to the URL. So people can optionally build there
> > >> >MM> web-apps just like they were used to when JSF wasn't around.
> > >> >
> > >> >MM> Good idea - bad idea - better idea ;) ?
> > >> >
> > >> >But I can't see how to do it in a general way while supporting both
> > >> >client and server side state saving modes. This is due, of course,
> > >> >to the restriction on size of the GET request.
> > >> >
> > >> >Another problem, when using the server side mode, is what to do when the
> > >> >session expires.
> > >> >
> > >> >Any solution that doesn't deal with these cases is a less than full
> > >> >solution.
> > >> >
> > >> >I was thinking of decorating the state manager to somehow write out
> > >> >bookmarked pages to the filesystem so they can survive session
> > >> >expiration, but then, what do you do about failover?
> > >> >
> > >> >Ed
> > >> >
> > >> >--
> > >> >| [EMAIL PROTECTED] | {home: 407 869 9587, office: 408 884 9519 OR
> > >> >x31640}
> > >> >| homepage: | http://purl.oclc.org/NET/edburns/
> > >> >| aim: edburns0sunw | iim: [EMAIL PROTECTED]
> > >> >
> > >>
> >
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
