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