BTW, a credit-where-it's-due: I should be clear that "my idea's
always been..." completely omits that this idea is very much
due to John Fallows!
-- Adam
On 1/27/06, Adam Winer <[EMAIL PROTECTED]> 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=#{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]
> > >
> >
>
