Considering the huge number of responses in this thread, this is
obviously a big problem. While there were good suggestions on how to
improve the situation, with all of them, we are only making (better)
alternatives to the broken base functionality. And yes, some say it's
not really broken because these types of web applications are not
meant to be bookmarked, but given that developers typically use view
names that mean something, the current behavior gets you the
distracting user experience that the URL looks like its always one
step behind the application state. Which is quite confusing to the end
users, and IMHO, way worse than using a single app URL with
parameters.
JSF needs to know the viewId so it can restore the correct component
tree, but the viewId to be restored shouldn't necessarily map to the
URL. Instead, if the commandLink would render a link to *the most
likely* outcome and pass in the current viewId either with POST or as
GET parameter, you'd get a system that'd would display meaningful URLs
in most cases.
You would only need to add something like this:
<to-view-id default="true">/editProfile.jsp</view>
And optionally, a "success" outcome could automatically be taken as
the default outcome for the action. In the failure cases, it'd still
be valid to display URL "/editProfile.jsf" even if you displayed an
error message such as "You need to login to edit your profile". Most
often, the URL would point to the starting point of that action, like
John described.
I don't see that this would be any worse to the current behavior in
any case, and would be better in most default cases. Then, on top of
this you could add even friendlier URLs or "partial state saving" with
GET parameters. Problem solved, no?
Kalle
On 1/30/06, John Fallows <[EMAIL PROTECTED]> wrote:
> Maybe I'm missing something, but I don't understand why state saving and
> bookmarking are related.
>
> Isn't a bookmark something you would potentially paste into an email and
> send to your friend? There doesn't seem to be any assosicated state present
> in the URL or on the server, so why do we need encryption?
>
> Perhaps this is related to traversing the same bookmarkable link while
> navigating within the application in the same browser session?
>
> Kind Regards,
> John Fallows.
>
>
> On 1/30/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> >
> > As for the security of proposal
> >
> > 2)
> >
> > if we do client-side state-saving, we do encryption, right? Would we
> > have to do encryption here, too, to make this more secure?
> >
> > Would that run against the notion of readable, nice bookmarks? Probably
> yes...
> >
> > regards,
> >
> > Martin
> >
> > On 1/30/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > Hi John,
> > >
> > > ok - so you agree with me that the renderer has to take care of that?
> > > Cause I still don't get that getURL stuff from the navigation-handler
> > > - It would be great if you could elaborate on that.
> > >
> > > as for saving parameters, I see three approaches cristalizing out now:
> > >
> > > 1) configure in the navigation rules what the URL will look like
> > > (which parameters are to be added, which beans they refer to) (John)
> > >
> > > 2) add parameters to the link, configure a saveState as bookmarkable,
> > > etc.. and write the renderer as such that this data is automatically
> > > added to the link and can be automatically applied by the faces
> > > backend (this is potentially insecure as you might be able to pass in
> > > any parameter, and set any bean property to any, potentially insecure
> > > value) (Matze & al)
> > >
> > > 3) try to get faces to do automatically the stuff it usually does
> > > (Jacob, Mario & al) - I haven't heard for this approach how partial
> > > state saving is supposed to be done - just have a partial state
> > > rendered, which is then applied to the URL?)
> > >
> > > is this listing somewhat correct? Please repost differently if you see
> > > something different.
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 1/30/06, John Fallows <[EMAIL PROTECTED]> wrote:
> > > > Thanks Adam! ;-)
> > > >
> > > > I've been thinking about this a bit more recently.
> > > >
> > > > One of the JSF's strengths is it's clean separation between
> agent-specific
> > > > details in the renderers, and it's more general component and event
> model
> > > > abstraction that can easily be leveraged by application developers.
> > > >
> > > > In the case of navigation and bookmarkability, I believe there is a
> danger
> > > > of getting caught up in the web application use case, and failing to
> > > > maintain this abstraction. For example, there has been some
> discussion of
> > > > consuming URL request parameters directly in the application
> definition.
> > > > Some folks might say that bookmarking only applies to web applications
> > > > anyway, so what's the big deal with breaking the abstraction here.
> Thinking
> > > > about this point helped me to realize that that although you might not
> > > > explicitly bookmark a dialog in your favorite Java development tool
> for
> > > > example, you would expect it to re-open the last project you were
> editing
> > > > when you next open that tool. I think this is a very similar feature
> to
> > > > bookmarking, just a bit more implicit, eg. auto-bookmark-on-exit.
> > > >
> > > > So, what are the properties of a bookmark? Well, I believe it
> defines an
> > > > entry-point for a flow, rather than a single page, with arbitrary
> > > > initialization requirements. For the web application case, this is
> > > > obviously an HTTP GET request with some request parameters, that need
> to be
> > > > pushed into a backing bean so they can be accessed during
> initialization of
> > > > the flow.
> > > >
> > > > Similar to the concept of a Converter together with UIInput
> processing
> > > > model in JSF, I think we need a bidirectional mapping for generation
> of the
> > > > bookmarkable URL and later initialization of the flow. As with all
> > > > agent-specific features in JSF, this should be routed through an API
> on the
> > > > RenderKit to maintain the appropriate abstraction layering, and an
> event
> > > > should be raised on the Flow/Page to allow initialization processing
> to
> > > > occur prior to initial rendering.
> > > >
> > > > The context in which the bookmarkable URL is defined would require
> access
> > > > to potentially locally scoped JSF variables, like "row", so the
> attachment
> > > > of bookmark parameters would need to be defined logically close to the
> > > > component hierarchy.
> > > >
> > > > <h:commandButton action="bookmarkShowRow" >
> > > > <f:param name="id" value="#{row.id}" />
> > > > </h:commandButton>
> > > >
> > > > One can imagine the CommandButtonRenderer generating a bookmark URL
> with an
> > > > id parameter, due to the "<bookmark>" definition below.
> > > >
> > > > Later processing of the bookmark request has no component hierarchy
> > > > available, so this needs to be defined in the context of the
> navigation
> > > > rules.
> > > >
> > > > <navigation-rule>
> > > > <outcome>bookmarkShowRow</outcome>
> > > > <to-view-id>showRow.jspx</to-view-id>
> > > > <bookmark>
> > > > <param>
> > > > <param-name>id</param-name>
> > > > <param-value>#{showRowBean.rowId}</param-value>
> > > > </param>
> > > > <action>showRowBean.onVisitBookmark</action>
> > > > </bookmark>
> > > > </navigation-rule>
> > > >
> > > > On initial render of showRow.jspx, the RenderKit can consume the id
> request
> > > > parameter to push it into the showRowBean's rowId property before
> processing
> > > > the initialization logic in the showRowBean onVisitBookmark method.
> > > >
> > > > Notice that there a no direct references to any request parameters,
> this is
> > > > implicitly managed by the RenderKit. The showRowBean is also defined
> by the
> > > > application developer, with no dependencies on the request.
> > > >
> > > > Now let's see what happens when this design is reused in the context
> of a
> > > > non-web application, say Telnet. ;-)
> > > >
> > > > Suppose we login to the telnet-based application and are presented
> with a
> > > > menu of options, with a list of user-defined "shortcuts" including
> your most
> > > > recently filed expense report. At the time this shortcut (bookmark)
> was
> > > > captured, only the expense report number was used, much like the above
> > > > example of row identifier. When the expense report shortcut is
> selected,
> > > > the application logic to initialize state is captured inside the
> showRowBean
> > > > as before. No changes are necessary in the application logic due to a
> > > > change in RenderKit, which is internally managing the rendering and
> decoding
> > > > of these bookmarkable shortcuts, and may choose any convenient
> strategy to
> > > > capture bookmark parameters.
> > > >
> > > > Anyway, just thinking out loud... ;-)
> > > >
> > > > Kind Regards,
> > > > John Fallows.
> > > >
> > > >
> > > > On 1/27/06, Adam Winer < [EMAIL PROTECTED]> wrote:
> > > > > 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]
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://apress.com/book/bookDisplay.html?bID=10044
> > > > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
>
> --
>
> http://apress.com/book/bookDisplay.html?bID=10044
> Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
