myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: Re: Bookmarking, History and JSF
Date Tue, 31 Jan 2006 06:16:57 GMT
Yeah, Kalle, you're absolutely right. I was thinking about that too -
if you have a fixed "action"-parameter or add a "defaultAction"
parameter to a link, you can already render the new view-id instead of
the old one.

But: you'll have to make sure that the postback somehow includes the
information on the old-view, if you don't do that, you'll mess up the
restore-state functionality.

regards,

Martin

On 1/31/06, Kalle Korhonen <kalle.korhonen@gmail.com> wrote:
> 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 <john.r.fallows@gmail.com> 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 <martin.marinschek@gmail.com> 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 <martin.marinschek@gmail.com> 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 <john.r.fallows@gmail.com> 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 < awiner@gmail.com> 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 < awiner@gmail.com> 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, jacob@hookom.net <jacob@hookom.net> 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 <
> > werpu@gmx.at>
> > > > > 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
> > > > > > > > >
> > > > > > > > >--
> > > > > > > > >| ed.burns@sun.com  | {home: 407 869 9587, office:
408 884 9519
> > OR
> > > > > x31640}
> > > > > > > > >| homepage:         |
> > > > > http://purl.oclc.org/NET/edburns/
> > > > > > > > >| aim: edburns0sunw | iim: ed.burns@sun.com
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces
Mime
View raw message