myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Fallows <john.r.fall...@gmail.com>
Subject Re: Re: Bookmarking, History and JSF
Date Mon, 30 Jan 2006 18:53:38 GMT
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

Mime
View raw message