> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 27, 2006 7:19 PM
> To: dev@myfaces.apache.org; dev@myfaces.apache.org
> Subject: Re: Bookmarking, History and JSF
>
> Unless I misunderstood--
>
> I've been saying you wouldn't want this though, because now
> your logic is bound to some assumption of previous state--
> where did the id come from, which is bad for GETs.
Why? all we need is a mapping mechanism that connects the url to
an action method of backing bean. All parameters are then
mapped to attributes of this same backing bean if the names
match. The rest is left as req-parms... the outcoming view-renderer
is determined from the outcome of the action-method...
I think no assumption of state here...
regards
Alexander
>
> You could pass the id, using EL evaluation of to-view-id,
> allowing a (separate) view decide how and where to map that
> #{param.id} into the succeeding request.
>
> -- Jacob
>
> >
> >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]
> >> >> >
> >> >>
> >>
>
