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
