myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Smirnov <>
Subject Re: Bookmarking, History and JSF
Date Fri, 27 Jan 2006 20:00:44 GMT
Yes ! I have any attempts to realize of same idea, but not solve one 
problem - it need  extend format of faces-config or make standalone 
configuration - not good

In most web-application cases we need bookmark not concrete page, but 
logical part of application.
In such cases best effect will be output entry point of part ( wizard 
start page, root of catalog etc ), what solved by such navigation handler

Adam Winer wrote:

>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=#{}</get-url>
And "default-action" for GET without parameters !

> </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.

View raw message