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