Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 9904 invoked from network); 30 Jan 2006 18:54:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 30 Jan 2006 18:54:05 -0000 Received: (qmail 62657 invoked by uid 500); 30 Jan 2006 18:54:03 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 62614 invoked by uid 500); 30 Jan 2006 18:54:03 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 62603 invoked by uid 99); 30 Jan 2006 18:54:03 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jan 2006 10:54:03 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of john.r.fallows@gmail.com designates 64.233.162.207 as permitted sender) Received: from [64.233.162.207] (HELO zproxy.gmail.com) (64.233.162.207) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jan 2006 10:54:01 -0800 Received: by zproxy.gmail.com with SMTP id m22so1256346nzf for ; Mon, 30 Jan 2006 10:53:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=AiYYLLLC5d4paTg84yIOIEvnHIVpi6zgBUEU9A0P8+BhB4iuMgdGk4VyU1pxvV6lZqyhwrJsQ3WJgdr9l0lRpR2TFVDW3veBGDeGEgGlvoCG6km55Z7R0bxxpEWzVFo4Jj+C2bSuRCqjU6cgzOyV9RkUp1X79eK6foOCMdYpQWQ= Received: by 10.65.197.1 with SMTP id z1mr1799502qbp; Mon, 30 Jan 2006 10:53:38 -0800 (PST) Received: by 10.65.73.4 with HTTP; Mon, 30 Jan 2006 10:53:38 -0800 (PST) Message-ID: <83caac420601301053i6c6ded6eh37270496fbecc89f@mail.gmail.com> Date: Mon, 30 Jan 2006 10:53:38 -0800 From: John Fallows To: MyFaces Development , mmarinschek@apache.org Subject: Re: Re: Bookmarking, History and JSF In-Reply-To: <5a99335f0601300019g32712863if5862699dcebbb59@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17849_6674339.1138647218798" References: <9616807.234741138377293939.JavaMail.servlet@perfora> <6dac79b90601270940l173e1da2i7e060fb52546c347@mail.gmail.com> <6dac79b90601270943k550bdefat814eb4f72df95146@mail.gmail.com> <83caac420601291757o31baae67mb7a67f9348ca2a9b@mail.gmail.com> <5a99335f0601300017g7e722951ka6d5622787f3b2d6@mail.gmail.com> <5a99335f0601300019g32712863if5862699dcebbb59@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_17849_6674339.1138647218798 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 presen= t 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 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 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 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 application= s > > > 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 no= t > > > 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 th= e > > > component hierarchy. > > > > > > > > > > > > > > > > > > One can imagine the CommandButtonRenderer generating a bookmark URL > with an > > > id parameter, due to the "" 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. > > > > > > > > > bookmarkShowRow > > > showRow.jspx > > > > > > > > > id > > > #{showRowBean.rowId} > > > > > > showRowBean.onVisitBookmark > > > > > > > > > > > > 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 abov= e > > > 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 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=3D"foo", into simple GET URLs. (The optional interfa= ce > 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=3D"#{row.showRow}" > > > > > ... could perhaps be handled as a GET too: > > > > > > > > > > myTable.jspx > > > > > #{row.showRow} > > > > > /faces/showRow.jspx?id=3D#{ row.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 funkie= r > > > 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 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: > > href=3D"/person.jsf?id=3D533">Click 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=DF 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 or > > > > > > >MM> 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 w= e > even > > > > > > >have an issue on our issue tracker for it: > > > > > > > > > > > > > > > > >https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=3D72 > > > > > > > > > > > > > >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 d= o > 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 writ= e > 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 951= 9 > OR > > > x31640} > > > > > > >| homepage: | > > > http://purl.oclc.org/NET/edburns/ > > > > > > >| aim: edburns0sunw | iim: ed.burns@sun.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > http://apress.com/book/bookDisplay.html?bID=3D10044 > > > 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=3D10044 Author: Pro JSF and Ajax: Building Rich Internet Components, Apress ------=_Part_17849_6674339.1138647218798 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Maybe I'm missing something, but I don't understand why state saving and bo= okmarking are related.

Isn't a bookmark something you would potentia= lly paste into an email and send to your friend?  There doesn't seem t= o be any assosicated state present in the URL or on the server, so why do w= e need encryption?

Perhaps this is related to traversing the same bookmarkable link wh= ile navigating within the application in the same browser session?

K= ind Regards,
John Fallows.

On 1/= 30/06,=20 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, t= oo, to make this more secure?

Would that run against the notion of r= eadable, 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-hand= ler
> - 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 loo= k like
> (which parameters are to be added, which beans they refer to= ) (John)
>
> 2) add parameters to the link, configure a saveSta= te as bookmarkable,
> etc.. and write the renderer as such that this data is automatical= ly
> added to the link and can be automatically applied by the faces<= br>> backend (this is potentially insecure as you might be able to pass = in
> any parameter, and set any bean property to any, potentially insec= ure
> 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
> some= thing different.
>
> regards,
>
> Martin
>
> On 1/30/06= , John Fallows <john.r.fallo= ws@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, an= d it's more general component and event model
> > abstraction that can easily be leveraged by application devel= opers.
> >
> >  In the case of navigation and b= ookmarkability, 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 direc= tly in the application definition.
> > Some folks might say that b= ookmarking only applies to web applications
> > anyway, so what's the big deal with breaking the abstraction = here.  Thinking
> > about this point helped me to realiz= e that that although you might not
> > explicitly bookmark a dialo= g 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 book= mark?  Well, I believe it defines an
> > entry-point for= a flow, rather than a single page, with arbitrary
> > initializat= ion requirements.  For the web application case, this is
> > obviously an HTTP GET request with some request parameters, t= hat need to be
> > pushed into a backing bean so they can be acces= sed during initialization of
> > the flow.
> >
> &g= t;  Similar to the concept of a Converter together with UIInput p= rocessing
> > model in JSF, I think we need a bidirectional mapping for gen= eration of the
> > bookmarkable URL and later initialization of th= e 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, a= nd an event
> > should be raised on the Flow/Page to allow initial= ization 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 boo= kmark parameters would need to be defined logically close to the
> > component hierarchy.
> >
> >  <= ;h:commandButton action=3D"bookmarkShowRow" >
> >&nbs= p;   <f:param name=3D"id" value=3D"#{row.id}" />
> >  </h:commandButton>
> >
> >=   One can imagine the CommandButtonRenderer generating a bookmark= URL with an
> > id parameter, due to the "<bookmark>&q= uot; definition below.
> >
> >  Later processing of the bookmark requ= est has no component hierarchy
> > available, so this needs to be = defined in the context of the navigation
> > rules.
> >> >  <navigation-rule>
> >    <outcome>bookmarkShowRow</out= come>
> >    <to-view-id>showRow.jspx= </to-view-id>
> >    <bookmark>> >      <param>
> >&nb= sp;       <param-name>id</param= -name>
> >        <param-valu= e>#{showRowBean.rowId}</param-value>
> >   = ;   </param>
> >     = ; <action>showRowBean.onVisitBookmark</action>
> >= ;    </bookmark>
> >  </navigation-rule>
> >
> >=   On initial render of showRow.jspx, the RenderKit can consume th= e id request
> > parameter to push it into the showRowBean's rowId= property before processing
> > the initialization logic in the showRowBean onVisitBookmark m= ethod.
> >
> >  Notice that there a no direct r= eferences to any request parameters, this is
> > implicitly manage= d 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 de= sign is reused in the context of a
> > non-web application, say Te= lnet. ;-)
> >
> >  Suppose we login to the telnet-based = application and are presented with a
> > menu of options, with a l= ist of user-defined "shortcuts" including your most
> > = recently filed expense report.  At the time this shortcut (bookma= rk) was
> > captured, only the expense report number was used, much like = the above
> > example of row identifier.  When the expen= se report shortcut is selected,
> > the application logic to initi= alize state is captured inside the showRowBean
> > as before.  No changes are necessary in the applica= tion logic due to a
> > change in RenderKit, which is internally m= anaging the rendering and decoding
> > of these bookmarkable short= cuts, and may choose any convenient strategy to
> > capture bookmark parameters.
> >
> > &= nbsp;Anyway, just thinking out loud... ;-)
> >
> > &= nbsp;Kind Regards,
> >  John Fallows.
> >
&g= t; >
> > 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 tha= t 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
> > > > {
> > > >   /**
> > &= gt; >    * Return an URL if the MethodExpression can= be handled purely
> > > >    * as a GET= request, or null if it cannot be done.
> > > >  &= nbsp; */
> > > >   public String getUrl(FacesContext, Meth= odExpression)
> > > > }
> > > >
> > = > > This would enable a NavigationHandler to turn constant
> &g= t; MethodExpressions,
> > > > like action=3D"foo", into simple GET URLs= .  (The optional interface idea
> > > > does run i= nto serious problems with any decorating NavigationHandlers;
> > &= gt; > ADF Faces uses a "Service" API kinda like the old MS OLE= IUnknown
> > > > QueryInterface approach, if you've had the misfortu= ne of developing
> > > > any OLE code in your career).
&g= t; > > >
> > > > It'd also allow a more sophisticat= ed NavigationHandler to provide
> > metadata
> > > > that says that for a specific= page, a more complicated action:
> > > >   action= =3D"#{row.showRow}"
> > > > ... could perhaps be h= andled as a GET too:
> > > >
> > > >  <from-view-id&= gt;myTable.jspx</from-view-id>
> > > >  &nbs= p; <action>#{row.showRow}
> > > >  &nbs= p; <get-url>/faces/showRow.jspx?id=3D#{=20 row.id}</get-url>
> > > >= ;  </from-view-id>
> > > >
> > >= > ... without any change in the page semantics.  This sort of= approach
> > > > also lets an application's architect chang= e up requirements, like
> > > > perhaps deciding that specific
> > > &g= t; app really does need to use postback for all requests, for funkier
&g= t; > requirements
> > > > like saving temporarily entered= results.  And you could do so without
> > > > forcing users to change back from outputLink to com= mandLink.
> > > >
> > > > -- Adam
> >= ; > >
> > > > On 1/27/06, jacob@hookom.net <jacob@hookom.n= et> wrote:
> > > > > I don't think the problem sho= uld be solved.
> > > > >
> > > > > No o= ne says that all of your commandLinks need to invoke actions-- you
> > can render normal links.  With invoking actions, yo= u posting transitional
> > behavior, with gets, there is not trans= itional behavior to retain.  When you
> > want to bookma= rk things, that designates the URI as repeatable, which is a
> > far separation from the intentions of JSF's action/stateful c= apabilities.
> > > > >
> > > > > Nothin= g is stopping someone from using JSF to render a table that
> > pr= ints out normal links like: <a
> > href=3D"/person.jsf?id=3D533">Click</a> an= d use RESTful
> > principles for actually rendering that page base= d 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 sh= ouldn't be.
> > > > >
> > > > > -- Jacob
> &= gt; > > >
> > > > > >
> > > > = > >Gru=DF Gott,
> > > > > >
> > > &g= t; > >>>>>> On Fri, 27 Jan 2006 10:43:23 +0100, Werner= Punz <=20 werpu@gmx.at>
> > said:
= > > > > > >
> > > > > >WP> +1000 = for a get....
> > > > > >WP> Martin Marinschek schr= ieb:
> > > > > >
> > > > > >MM> I'= m having ideas again. Must come from too much work with JSF ;)
> >= > > > >MM>
> > > > > >MM> My idea:
> > > > > >MM>
> > > > > >MM&= gt; Bookmarking is a problem with JSF, right? Except you use
> > h= :outputLink,
> > > > > >MM> but then there's this s= light 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 st= ate is not so important at
> > all.
> > > > > &g= t;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:commandLin= k /> 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?
> > &g= t; > > >MM>
> > > > > >MM> The developer can decide then:
&= gt; > > > > >MM> - do I need this link to be bookmarked> > > > > >MM> - do I want this link to  u= se the plain old JSF posting system
> > with
> > > > > >MM> state-saving.
= > > > > > >
> > > > > >Right, I've t= hought about this problem for the Sun impl, and we even
> > > &= gt; > >have an issue on our issue tracker for it:
> > > > > >
> > > > >
> > = >https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=3D72=
> > > > > >
> > > > > >MM> Enhanc= ement: 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 li= ke they were used to when JSF wasn't around.
> > > > > &g= t;
> > > > > >MM> Good idea - bad idea - better ide= a ;) ?
> > > > > >
> > > > > >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 requ= est.
> > > > > >
> > > > > >Anoth= er problem, when using the server side mode, is what to do when
> >= ; the
> > > > > >session expires.
> > > > &g= t; >
> > > > > >Any solution that doesn't deal with= these cases is a less than full
> > > > > >solution.
> > > > > >
> > > > > >I was thi= nking of decorating the state manager to somehow write out
> > >= ; > > >bookmarked pages to the filesystem so they can survive sess= ion
> > > > > >expiration, but then, what do you do about= failover?
> > > > > >
> > > > > >= ;Ed
> > > > > >
> > > > > >--
> > > > > >| ed.b= urns@sun.com  | {home: 407 869 9587, office: 408 884 9519 OR<= br>> > x31640}
> > > > > >| homepage:  = ;       |
> >=20 http://purl.oclc.org/NET/edbu= rns/
> > > > > >| aim: edburns0sunw | iim: ed.burns@sun.com
> > > > &g= t; >
> > > > >
> > > >
> > >
&g= t; >
> >
> >
> > --
> > http://apress.com/book/= bookDisplay.html?bID=3D10044
> > Author: Pro JSF and Ajax: Building Rich Internet Componen= ts, Apress
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse - > JSF Consulting, Development and
> Courses in English and German<= br>>
> Professional Support for Apache MyFaces
>


= --

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in Engl= ish and German

Professional Support for Apache MyFaces



--
http://apress.com/book/bookDisplay.html?bID=3D10044
Author: Pro JSF = and Ajax: Building Rich Internet Components, Apress=20 ------=_Part_17849_6674339.1138647218798--