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