Re: status of the optional validator stuff [Was: Bookmarking, History and JSF]
I wonder where that is. If I look into UIInput, it calls in restoreState/saveState saveAttachedState on the validators. Now that should save and restore the state of the validators, right? Maybe there's something in the tag which kills them again. regards, Martin On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > I'm looking through the JSF 1.1 spec. > I don't actually see where validators get recreated rather than > restored. In fact the spec seems to indicate the opposite. Yet, > that's the behavior. > I'm also looking through myfaces api, and again I can't see where it's > happening, but it's happening somewhere. > > On 2/8/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > You're sure there are any API changes? > > > > If there aren't, we might get through... > > > > Why do we need special tree-building for this? That's in fact just > > like creating child-components, right? > > > > regards, > > > > Martin > > > > On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > > I don't know, but I suspect it'd break the TCK. 1.2 corrected the > > > 1.1 design flaw, so I'm guessing it's required in 1.1. > > > > > > On 2/8/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > > Does it require API changes or would it break the TCK if we would go > > > > "1.2" compatible here? > > > > > > > > regards, > > > > > > > > Martin > > > > > > > > On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > > > > On 1/31/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > > > > By the way - any update on the optional validator stuff together > > > > > > with > > > > > > partial validation? Ok, maybe we should start a different thread on > > > > > > this ;) > > > > > > > > > > I finally got around to updating the wiki page. > > > > > > > > > > The short answer is that it works fine as long as you're also using > > > > > facelets. It should also work if you're using JSF 1.2. It can't > > > > > work with standard JSF 1.1 component tree building rules. > > > > > > > > > > = > > > > > Known issues > > > > > > > > > > * JSF 1.1 recreates validators and converters each request. This > > > > > makes it difficult (maybe impossible) to implement a validator element > > > > > that wraps other validator elements. Thus, you must also use facelets > > > > > with JSF 1.1 in order to use the optional validation framework. > > > > > > > > > > > > > > > > > -- > > > > > > > > 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://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: status of the optional validator stuff [Was: Bookmarking, History and JSF]
> -Original Message- > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 08, 2006 11:08 PM > To: MyFaces Development > Subject: Fwd: status of the optional validator stuff [Was: > Bookmarking, History and JSF] > > -- Forwarded message -- > From: Martin Marinschek <[EMAIL PROTECTED]> > Date: Feb 8, 2006 11:07 PM > Subject: Re: status of the optional validator stuff [Was: Bookmarking, > History and JSF] > To: Mike Kienenberger <[EMAIL PROTECTED]> > > > You're sure there are any API changes? > > If there aren't, we might get through... > > Why do we need special tree-building for this? That's in fact just > like creating child-components, right? What he might be hinting at is: JSF 1.1 as it works: Somehow the validators are not allowed to have child components. It would be easier to be able to just add in lots of cases. Plus. As Mike points out: it is almost impossible to recreate the component tree correctly with the validators. Although I still have hope to find the hole... Maybe if I fork the sources and separate it from the facelets-version, who knows... Fact is: we need the OptionaValidators urgently... the number of emails and forum-entries just show it. It is definitely a fault of the JSF 1.1 spec. Fact is also: It's a major PITA to get it down... Question is now: Do we have enough need to get it working for JSF 1.1 or should we just concentrate of JSF 1.2? Can we ask of everybody to go for facelets?... regards Alexander PS: Maybe I should nag Ed about it... but he most probably just says: "Go for 1.2"... > > regards, > > Martin > > On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > I don't know, but I suspect it'd break the TCK. 1.2 corrected the > > 1.1 design flaw, so I'm guessing it's required in 1.1. > > > > On 2/8/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > Does it require API changes or would it break the TCK if > we would go > > > "1.2" compatible here? > > > > > > regards, > > > > > > Martin > > > > > > On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > > > On 1/31/06, Martin Marinschek > <[EMAIL PROTECTED]> wrote: > > > > > By the way - any update on the optional validator > stuff together with > > > > > partial validation? Ok, maybe we should start a > different thread on > > > > > this ;) > > > > > > > > I finally got around to updating the wiki page. > > > > > > > > The short answer is that it works fine as long as > you're also using > > > > facelets. It should also work if you're using JSF > 1.2. It can't > > > > work with standard JSF 1.1 component tree building rules. > > > > > > > > = > > > > Known issues > > > > > > > > * JSF 1.1 recreates validators and converters each > request. This > > > > makes it difficult (maybe impossible) to implement a > validator element > > > > that wraps other validator elements. Thus, you must > also use facelets > > > > with JSF 1.1 in order to use the optional validation framework. > > > > > > > > > > > > > -- > > > > > > 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://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
Fwd: status of the optional validator stuff [Was: Bookmarking, History and JSF]
-- Forwarded message -- From: Martin Marinschek <[EMAIL PROTECTED]> Date: Feb 8, 2006 11:07 PM Subject: Re: status of the optional validator stuff [Was: Bookmarking, History and JSF] To: Mike Kienenberger <[EMAIL PROTECTED]> You're sure there are any API changes? If there aren't, we might get through... Why do we need special tree-building for this? That's in fact just like creating child-components, right? regards, Martin On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > I don't know, but I suspect it'd break the TCK. 1.2 corrected the > 1.1 design flaw, so I'm guessing it's required in 1.1. > > On 2/8/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > Does it require API changes or would it break the TCK if we would go > > "1.2" compatible here? > > > > regards, > > > > Martin > > > > On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > > On 1/31/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > > By the way - any update on the optional validator stuff together with > > > > partial validation? Ok, maybe we should start a different thread on > > > > this ;) > > > > > > I finally got around to updating the wiki page. > > > > > > The short answer is that it works fine as long as you're also using > > > facelets. It should also work if you're using JSF 1.2. It can't > > > work with standard JSF 1.1 component tree building rules. > > > > > > = > > > Known issues > > > > > > * JSF 1.1 recreates validators and converters each request. This > > > makes it difficult (maybe impossible) to implement a validator element > > > that wraps other validator elements. Thus, you must also use facelets > > > with JSF 1.1 in order to use the optional validation framework. > > > > > > > > > -- > > > > 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://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: status of the optional validator stuff [Was: Bookmarking, History and JSF]
Love to, but I'm just completely overwhelmed these days. I haven't even had time to create examples yet for the distribution. On 2/8/06, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > Unfortunately I have to say that it is true for the JSF 1.1 part... > Just breaks every other time... > > Though I tend not to give up... > > Anyway Mike... how about tagging the actual stuff as 1.1-facelets > and put up a new set of jar-files at jsf-comp? > > regards > Alexander > > > -Original Message- > > From: Mike Kienenberger [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 08, 2006 7:02 PM > > To: MyFaces Development; [EMAIL PROTECTED] > > Subject: status of the optional validator stuff [Was: > > Bookmarking, History and JSF] > > > > On 1/31/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > By the way - any update on the optional validator stuff > > together with > > > partial validation? Ok, maybe we should start a different thread on > > > this ;) > > > > I finally got around to updating the wiki page. > > > > The short answer is that it works fine as long as you're also using > > facelets. It should also work if you're using JSF 1.2. It can't > > work with standard JSF 1.1 component tree building rules. > > > > = > > Known issues > > > > * JSF 1.1 recreates validators and converters each request. This > > makes it difficult (maybe impossible) to implement a validator element > > that wraps other validator elements. Thus, you must also use facelets > > with JSF 1.1 in order to use the optional validation framework. > > >
RE: status of the optional validator stuff [Was: Bookmarking, History and JSF]
Unfortunately I have to say that it is true for the JSF 1.1 part... Just breaks every other time... Though I tend not to give up... Anyway Mike... how about tagging the actual stuff as 1.1-facelets and put up a new set of jar-files at jsf-comp? regards Alexander > -Original Message- > From: Mike Kienenberger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 08, 2006 7:02 PM > To: MyFaces Development; [EMAIL PROTECTED] > Subject: status of the optional validator stuff [Was: > Bookmarking, History and JSF] > > On 1/31/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > By the way - any update on the optional validator stuff > together with > > partial validation? Ok, maybe we should start a different thread on > > this ;) > > I finally got around to updating the wiki page. > > The short answer is that it works fine as long as you're also using > facelets. It should also work if you're using JSF 1.2. It can't > work with standard JSF 1.1 component tree building rules. > > = > Known issues > > * JSF 1.1 recreates validators and converters each request. This > makes it difficult (maybe impossible) to implement a validator element > that wraps other validator elements. Thus, you must also use facelets > with JSF 1.1 in order to use the optional validation framework. >
Re: status of the optional validator stuff [Was: Bookmarking, History and JSF]
I don't know, but I suspect it'd break the TCK. 1.2 corrected the 1.1 design flaw, so I'm guessing it's required in 1.1. On 2/8/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Does it require API changes or would it break the TCK if we would go > "1.2" compatible here? > > regards, > > Martin > > On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > On 1/31/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > By the way - any update on the optional validator stuff together with > > > partial validation? Ok, maybe we should start a different thread on > > > this ;) > > > > I finally got around to updating the wiki page. > > > > The short answer is that it works fine as long as you're also using > > facelets. It should also work if you're using JSF 1.2. It can't > > work with standard JSF 1.1 component tree building rules. > > > > = > > Known issues > > > > * JSF 1.1 recreates validators and converters each request. This > > makes it difficult (maybe impossible) to implement a validator element > > that wraps other validator elements. Thus, you must also use facelets > > with JSF 1.1 in order to use the optional validation framework. > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
Re: status of the optional validator stuff [Was: Bookmarking, History and JSF]
Does it require API changes or would it break the TCK if we would go "1.2" compatible here? regards, Martin On 2/8/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > On 1/31/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > By the way - any update on the optional validator stuff together with > > partial validation? Ok, maybe we should start a different thread on > > this ;) > > I finally got around to updating the wiki page. > > The short answer is that it works fine as long as you're also using > facelets. It should also work if you're using JSF 1.2. It can't > work with standard JSF 1.1 component tree building rules. > > = > Known issues > > * JSF 1.1 recreates validators and converters each request. This > makes it difficult (maybe impossible) to implement a validator element > that wraps other validator elements. Thus, you must also use facelets > with JSF 1.1 in order to use the optional validation framework. > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
status of the optional validator stuff [Was: Bookmarking, History and JSF]
On 1/31/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > By the way - any update on the optional validator stuff together with > partial validation? Ok, maybe we should start a different thread on > this ;) I finally got around to updating the wiki page. The short answer is that it works fine as long as you're also using facelets. It should also work if you're using JSF 1.2. It can't work with standard JSF 1.1 component tree building rules. = Known issues * JSF 1.1 recreates validators and converters each request. This makes it difficult (maybe impossible) to implement a validator element that wraps other validator elements. Thus, you must also use facelets with JSF 1.1 in order to use the optional validation framework.
RE: Bookmarking, History and JSF
> -Original Message- > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 31, 2006 12:04 PM > To: MyFaces Development > Subject: Re: Bookmarking, History and JSF > > Ok, I've discussed with Manfred and Thomas some more, and our personal > preference would be proposal 2 with (optional) encryption (or > signature, just so that the user can't temper with the URL). Option 1 would also enable outside-applications to generate correct links and therefor can be attractive for corporations having lots of interacting web-apps.. > > regards, > > Martin > -Original Message- > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 31, 2006 12:06 PM > To: MyFaces Development > Subject: Re: Bookmarking, History and JSF > > Ok, I'll implement the interface, you the simple server store > implementation - is that a deal ;) ? Should be possible... > > By the way - any update on the optional validator stuff together with > partial validation? Ok, maybe we should start a different thread on > this ;) Sorry, am still setting me up again to continue work on the OV... But PV is one of the first things I want to check... So many loose ends to check and tie up ... regards Alexander > > regards, > > Martin > > On 1/31/06, Jesse Alexander (KBSA 21) > <[EMAIL PROTECTED]> wrote: > > > > > > > -Original Message- > > > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, January 31, 2006 11:58 AM > > > To: MyFaces Development > > > Subject: Re: Bookmarking, History and JSF > > > > > > Yeah - but where do you store these tinyurls? On the server? > > > In a database? > > > > Offer an interface that can be implemented by a developer, allowing > > for DB-persistance, plus deliver a simple implementation using a > > file-store? > > > > regards > > Alexander > > > > > > > > +1 for making it configurable, -1 for making it the default ;) > > > > > > regards, > > > > > > Martin > > > > > > On 1/31/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > > > Regardless of the solution we use, we should abstract the > > > creation of > > > > > the url so one can replace it with its own implementation. > > > > > > > > +1 an abstract *layer* sounds good > > > > +1 for tinyurl like urls! > > > > > > > > -Matthias > > > > > > > > > I see three types of them: > > > > > > > > > > *) plain - pass through (so hackable) > > > > > *) encryption (leads to become too large for a GET) > > > > > *) leases - I have done this in one of my projects. The > > > user is able to > > > > > bookmark a page but only gets a lease-ID. The server > > > stores the correct > > > > > url for this lease (something like tinyurl) - not > > > hackable, repeatable, > > > > > and no size limit - we just need a parameter to let a > > > lease die if not > > > > > used for a couple of month > > > > > > > > > > > > > > > --- > > > > > Mario > > > > > > > > > > > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > Zülpicher Wall 12, 239 > > > > 50674 Köln > > > > http://www.wessendorf.net > > > > mwessendorf-at-gmail-dot-com > > > > > > > > > > > > > -- > > > > > > 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 >
Re: Bookmarking, History and JSF
Ok, I'll implement the interface, you the simple server store implementation - is that a deal ;) ? By the way - any update on the optional validator stuff together with partial validation? Ok, maybe we should start a different thread on this ;) regards, Martin On 1/31/06, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 31, 2006 11:58 AM > > To: MyFaces Development > > Subject: Re: Bookmarking, History and JSF > > > > Yeah - but where do you store these tinyurls? On the server? > > In a database? > > Offer an interface that can be implemented by a developer, allowing > for DB-persistance, plus deliver a simple implementation using a > file-store? > > regards > Alexander > > > > > +1 for making it configurable, -1 for making it the default ;) > > > > regards, > > > > Martin > > > > On 1/31/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > > Regardless of the solution we use, we should abstract the > > creation of > > > > the url so one can replace it with its own implementation. > > > > > > +1 an abstract *layer* sounds good > > > +1 for tinyurl like urls! > > > > > > -Matthias > > > > > > > I see three types of them: > > > > > > > > *) plain - pass through (so hackable) > > > > *) encryption (leads to become too large for a GET) > > > > *) leases - I have done this in one of my projects. The > > user is able to > > > > bookmark a page but only gets a lease-ID. The server > > stores the correct > > > > url for this lease (something like tinyurl) - not > > hackable, repeatable, > > > > and no size limit - we just need a parameter to let a > > lease die if not > > > > used for a couple of month > > > > > > > > > > > > --- > > > > Mario > > > > > > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > Zülpicher Wall 12, 239 > > > 50674 Köln > > > http://www.wessendorf.net > > > mwessendorf-at-gmail-dot-com > > > > > > > > > -- > > > > 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
Re: Bookmarking, History and JSF
Ok, I've discussed with Manfred and Thomas some more, and our personal preference would be proposal 2 with (optional) encryption (or signature, just so that the user can't temper with the URL). regards, Martin On 1/31/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Martin Marinschek schrieb: > > Yeah - but where do you store these tinyurls? On the server? In a database? > > > Yes, in an database. > > > +1 for making it configurable, -1 for making it the default ;) > > > +1 - thats exactly what I thought! > > Ciao, > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Bookmarking, History and JSF
> -Original Message- > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 31, 2006 11:58 AM > To: MyFaces Development > Subject: Re: Bookmarking, History and JSF > > Yeah - but where do you store these tinyurls? On the server? > In a database? Offer an interface that can be implemented by a developer, allowing for DB-persistance, plus deliver a simple implementation using a file-store? regards Alexander > > +1 for making it configurable, -1 for making it the default ;) > > regards, > > Martin > > On 1/31/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > Regardless of the solution we use, we should abstract the > creation of > > > the url so one can replace it with its own implementation. > > > > +1 an abstract *layer* sounds good > > +1 for tinyurl like urls! > > > > -Matthias > > > > > I see three types of them: > > > > > > *) plain - pass through (so hackable) > > > *) encryption (leads to become too large for a GET) > > > *) leases - I have done this in one of my projects. The > user is able to > > > bookmark a page but only gets a lease-ID. The server > stores the correct > > > url for this lease (something like tinyurl) - not > hackable, repeatable, > > > and no size limit - we just need a parameter to let a > lease die if not > > > used for a couple of month > > > > > > > > > --- > > > Mario > > > > > > > > > > > > -- > > Matthias Wessendorf > > Zülpicher Wall 12, 239 > > 50674 Köln > > http://www.wessendorf.net > > mwessendorf-at-gmail-dot-com > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
Re: Bookmarking, History and JSF
Martin Marinschek schrieb: > Yeah - but where do you store these tinyurls? On the server? In a database? > Yes, in an database. > +1 for making it configurable, -1 for making it the default ;) > +1 - thats exactly what I thought! Ciao, Mario
Re: Bookmarking, History and JSF
Yeah - but where do you store these tinyurls? On the server? In a database? +1 for making it configurable, -1 for making it the default ;) regards, Martin On 1/31/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > Regardless of the solution we use, we should abstract the creation of > > the url so one can replace it with its own implementation. > > +1 an abstract *layer* sounds good > +1 for tinyurl like urls! > > -Matthias > > > I see three types of them: > > > > *) plain - pass through (so hackable) > > *) encryption (leads to become too large for a GET) > > *) leases - I have done this in one of my projects. The user is able to > > bookmark a page but only gets a lease-ID. The server stores the correct > > url for this lease (something like tinyurl) - not hackable, repeatable, > > and no size limit - we just need a parameter to let a lease die if not > > used for a couple of month > > > > > > --- > > Mario > > > > > > > -- > Matthias Wessendorf > Zülpicher Wall 12, 239 > 50674 Köln > http://www.wessendorf.net > mwessendorf-at-gmail-dot-com > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
> Regardless of the solution we use, we should abstract the creation of > the url so one can replace it with its own implementation. +1 an abstract *layer* sounds good +1 for tinyurl like urls! -Matthias > I see three types of them: > > *) plain - pass through (so hackable) > *) encryption (leads to become too large for a GET) > *) leases - I have done this in one of my projects. The user is able to > bookmark a page but only gets a lease-ID. The server stores the correct > url for this lease (something like tinyurl) - not hackable, repeatable, > and no size limit - we just need a parameter to let a lease die if not > used for a couple of month > > > --- > Mario > > -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
Re: Bookmarking, History and JSF
Hi! > In proposal 2 (see above) the use-data _and_ the structure is > transferred to the client, so by changing the structure, the (hacking) > user can try to recreate and set any properties on any bean on the > server, if no encryption is used. > Regardless of the solution we use, we should abstract the creation of the url so one can replace it with its own implementation. I see three types of them: *) plain - pass through (so hackable) *) encryption (leads to become too large for a GET) *) leases - I have done this in one of my projects. The user is able to bookmark a page but only gets a lease-ID. The server stores the correct url for this lease (something like tinyurl) - not hackable, repeatable, and no size limit - we just need a parameter to let a lease die if not used for a couple of month --- Mario
Re: Re: Bookmarking, History and JSF
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 <[EMAIL PROTECTED]> 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: > /editProfile.jsp > 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 > > mod
Re: Re: Bookmarking, History and JSF
Well, for your suggestion, no state saving is necessary, right. you'll only have "use-data" transferred via the wire to the client, so that's somewhat ok. In proposal 2 (see above) the use-data _and_ the structure is transferred to the client, so by changing the structure, the (hacking) user can try to recreate and set any properties on any bean on the server, if no encryption is used. regards, Martin 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. > > > > > > > >
Re: Re: Bookmarking, History and JSF
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: /editProfile.jsp 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 > > >
Re: Re: Bookmarking, History and JSF
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 proposal2)if we do client-side state-saving, we do encryption, right? Would wehave to do encryption here, too, to make this more secure?Would that run against the notion of readable, nice bookmarks? Probably yes...
regards,MartinOn 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.> >> > > >row.id}" />
> > > >> > 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
> > t
Re: Re: Bookmarking, History and JSF
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.
> >
> >
> >
> >
> >
> > 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 t
Re: Re: Bookmarking, History and JSF
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.
>
>
>
>
>
> 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 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 R
Re: Re: Bookmarking, History and JSF
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.
row.id}" />
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 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'salways been..." completely omits that this idea is very muchdue to John Fallows!-- AdamOn 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="" 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:
>
Re: Bookmarking, History and JSF
You're a philosoph, Jacob ;) So how do we go about saving partial-state? regards, Martin On 1/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > What Mario is suggesting is the foundation for my stateless JSF solution. It > doesn't make sense to duplicate the cabilities of a component framework and > jam it into a struts/webwork solution-- around validation, parameter > handling, and action invocation. > > Your JSF document, with all of its components, is the tip of the iceberg of > lots of functionality and behavior. Going back to the Avatar blogs, the > importance of identity carries a very light-weight, agnostic way of > transferring state to component handler on succeeding gets or posts via AJAX > or normal submit. There's absolutely no need to re-invent the wheel here. > > -- Jacob > > > > >Ok, I see... > > > >hmm, we'll have to think about that. > > > >regards, > > > >Martin > > > >On 1/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > >> Hi! > >> > I don't get it - you usually don't save stuff like id's in the > >> > component tree, so how would it help you to apply an id to an item in > >> > the component tree? > >> > > >> No id? > >> I talked about the same id (client-id) you use to pass the request POST > >> parameters into the view. > >> > >> So I don't talk about anything new to do, just to process the GET > >> request the same way as you do with POST. And maybe do something special > >> for the action, but I guess even this isn't needed. > >> > >> This allows you to render a commandLink with the new javascript=false > >> and get a bookmarkable page. As always - the user has to ensure enough > >> information will be passed to the view so it can recreate its internal > >> state - even if the request created a new session. > >> > >> --- > >> Mario > >> > >> > > > > > >-- > > > >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
Re: Bookmarking, History and JSF
What Mario is suggesting is the foundation for my stateless JSF solution. It doesn't make sense to duplicate the cabilities of a component framework and jam it into a struts/webwork solution-- around validation, parameter handling, and action invocation. Your JSF document, with all of its components, is the tip of the iceberg of lots of functionality and behavior. Going back to the Avatar blogs, the importance of identity carries a very light-weight, agnostic way of transferring state to component handler on succeeding gets or posts via AJAX or normal submit. There's absolutely no need to re-invent the wheel here. -- Jacob > >Ok, I see... > >hmm, we'll have to think about that. > >regards, > >Martin > >On 1/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: >> Hi! >> > I don't get it - you usually don't save stuff like id's in the >> > component tree, so how would it help you to apply an id to an item in >> > the component tree? >> > >> No id? >> I talked about the same id (client-id) you use to pass the request POST >> parameters into the view. >> >> So I don't talk about anything new to do, just to process the GET >> request the same way as you do with POST. And maybe do something special >> for the action, but I guess even this isn't needed. >> >> This allows you to render a commandLink with the new javascript=false >> and get a bookmarkable page. As always - the user has to ensure enough >> information will be passed to the view so it can recreate its internal >> state - even if the request created a new session. >> >> --- >> Mario >> >> > > >-- > >http://www.irian.at > >Your JSF powerhouse - >JSF Consulting, Development and >Courses in English and German > >Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
Ok, I see... hmm, we'll have to think about that. regards, Martin On 1/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > I don't get it - you usually don't save stuff like id's in the > > component tree, so how would it help you to apply an id to an item in > > the component tree? > > > No id? > I talked about the same id (client-id) you use to pass the request POST > parameters into the view. > > So I don't talk about anything new to do, just to process the GET > request the same way as you do with POST. And maybe do something special > for the action, but I guess even this isn't needed. > > This allows you to render a commandLink with the new javascript=false > and get a bookmarkable page. As always - the user has to ensure enough > information will be passed to the view so it can recreate its internal > state - even if the request created a new session. > > --- > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
Hi! > I don't get it - you usually don't save stuff like id's in the > component tree, so how would it help you to apply an id to an item in > the component tree? > No id? I talked about the same id (client-id) you use to pass the request POST parameters into the view. So I don't talk about anything new to do, just to process the GET request the same way as you do with POST. And maybe do something special for the action, but I guess even this isn't needed. This allows you to render a commandLink with the new javascript=false and get a bookmarkable page. As always - the user has to ensure enough information will be passed to the view so it can recreate its internal state - even if the request created a new session. --- Mario
Re: Bookmarking, History and JSF
hmm I don't get it - you usually don't save stuff like id's in the component tree, so how would it help you to apply an id to an item in the component tree? Or did I get you wrong here? regards, Martin On 1/29/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > - If the bean is request-scoped, it forces you to get this parameter > > into every request - a major challenge for postback in JSF. > > > Ok, this is really a problem when using param.name > > - You have to very carefully check incoming parameter values > > for legitimacy (in a way that JSF components often can handle > > automagically) since no validation will be performed by the system. > > > Is there somehting in jsf 1.2 which allows to annotate settters with > validators? > > - Painful coupling between the target page, consuming the URL, > >and the source page, generating the query parameter. > > > Is is really that bad? Using reflection you have the coupling between > url and bean, is this any better? > > So a solution to this might be to set the submittedValue of a component > and let faces do the rest. > What I mean is: > > *) The url points to the view-ID > *) faces will create the view > *) a phase listener (or whatever) will try to lookup the components by > id and set the submittedValue based on the url parameters - as it does > for POST, but for GET too. > *) at least for sure, the url need some informations for faces to call > an actions (eg: _action=cmdLinkId) - or even better, use the already > existent hidden value to pass in the action (dont know the name now, > _jsp_link ?) > > So the url could be something like this: > http://server/ctx/documentView.faces?searchForm.documentId=4711&_action=searchForm.searchDocument > Note: searchForm.searchDocument is the clientId of a command link and > not the bean action method. > > now you are fine, we use the power of the component tree to ensure valid > parameters and are still able to use saveState to transfer the bean from > one request to another. > > The bookmark page can be the page itself, of only a bridge to the real > page as due to the action character faces will still apply any > navigation rule to it. > > The user should be told always to use the id, else any change on the > component tree will result in invalid bookmark urls due to the changed ids. > > For what I know this also requires at first only one change, e.g. > process the GET stuff too. > > To create a link to a bookmarkable page we can extend commandLink wit a > parameter something like javascript=false so it will render like it do > if you configure ALLOW_JAVASCRIPT=false > > --- > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
Hi! > - If the bean is request-scoped, it forces you to get this parameter > into every request - a major challenge for postback in JSF. > Ok, this is really a problem when using param.name > - You have to very carefully check incoming parameter values > for legitimacy (in a way that JSF components often can handle > automagically) since no validation will be performed by the system. > Is there somehting in jsf 1.2 which allows to annotate settters with validators? > - Painful coupling between the target page, consuming the URL, >and the source page, generating the query parameter. > Is is really that bad? Using reflection you have the coupling between url and bean, is this any better? So a solution to this might be to set the submittedValue of a component and let faces do the rest. What I mean is: *) The url points to the view-ID *) faces will create the view *) a phase listener (or whatever) will try to lookup the components by id and set the submittedValue based on the url parameters - as it does for POST, but for GET too. *) at least for sure, the url need some informations for faces to call an actions (eg: _action=cmdLinkId) - or even better, use the already existent hidden value to pass in the action (dont know the name now, _jsp_link ?) So the url could be something like this: http://server/ctx/documentView.faces?searchForm.documentId=4711&_action=searchForm.searchDocument Note: searchForm.searchDocument is the clientId of a command link and not the bean action method. now you are fine, we use the power of the component tree to ensure valid parameters and are still able to use saveState to transfer the bean from one request to another. The bookmark page can be the page itself, of only a bridge to the real page as due to the action character faces will still apply any navigation rule to it. The user should be told always to use the id, else any change on the component tree will result in invalid bookmark urls due to the changed ids. For what I know this also requires at first only one change, e.g. process the GET stuff too. To create a link to a bookmarkable page we can extend commandLink wit a parameter something like javascript=false so it will render like it do if you configure ALLOW_JAVASCRIPT=false --- Mario
Re: Bookmarking, History and JSF
Craig,
Well, I definitely agree that any sort of auto-population is very, very
worrisome. But, using #{param.foo} for a managed
property still leaves behind some major problems:
- If the bean is request-scoped, it forces you to get this parameter
into every request - a major challenge for postback in JSF.
- You have to very carefully check incoming parameter values
for legitimacy (in a way that JSF components often can handle
automagically) since no validation will be performed by the system.
- Painful coupling between the target page, consuming the URL,
and the source page, generating the query parameter.
... which is why a good solution to the problem involves a really smart
navigation handler (plus other parts of a JSF system) that can automate
the generation of such URLs *and* the inteilligent consumption on the
target page.
-- Adam
On 1/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 1/28/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > [snip]
> > Now the phase listener has the convention, that "foo" and "bar" are
> > the bean properties
> > and populates the bean with the given values.
>
> If the destination bean is itself a managed bean, you can actually avoid
> this restriction, by allowing the bean itself to configure capturing
> interesting request parameters with an expression like this in a
> element:
>
> #{param.foo}
>
> #{param.bar}
>
> This would also avoid cases where the backing bean just happens to have a
> property with the same name as one of the request parameters, which will get
> modified by your logic (and could lead to a variety of DOS attacks by
> clients that add spurious parameter values).
>
> Craig
>
>
Re: Bookmarking, History and JSF
On 1/28/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
[snip]Now the phase listener has the convention, that "foo" and "bar" arethe bean propertiesand populates the bean with the given values.If the destination bean is itself a managed bean, you can actually avoid this restriction, by allowing the bean itself to configure capturing interesting request parameters with an _expression_ like this in a element:
#{param.foo} #{param.bar}This would also avoid cases where the backing bean just happens to have a property with the same name as one of the request parameters, which will get modified by your logic (and could lead to a variety of DOS attacks by clients that add spurious parameter values).
Craig
Re: Bookmarking, History and JSF
Hi
> Now the phase listener has the convention, that "foo" and "bar" are
> the bean properties
> and populates the bean with the given values.
>
I tried to follow the thread in full, but sometimes I dont get the point
of ones objection.
Sorry, if this has already been discussed, but:
Why cant we use the managed-property stuff and thus #{param.name}?
This detaches the url naming from the real meaning of the property.
And any other bean initialized within the request is able to get in
touch with the parameter - if wanted.
Another question I have is the way we allow the user to bookmark a page.
For what I know we have to make a page bookmark aware, isnt it?
At least the view (and its backing bean) should be able to work with a
minimum on information.
So why not simply render a "bookmark this page" link simply by using
outputLink?
So the only thing we really have to make work is the access to the GET
parameters, isnt it?
Whats the point to make it more complicated?
Sorry, if this all sounds too "newbie"! ;-)
---
Mario
Re: Bookmarking, History and JSF
Hi Matze,
that looks real nice...
I think in the end, we'll additionally have some form of url-rewrite
in place to be able to specify the stuff without parameters, but just
appending one directory after the other.
Now, I didn't quite get the story with the bookmarkable URL which is
sent by the navigation-handler. Excuse my ignorance, I don't get it.
I can see that if you have that navigation-handler in place, it will
return a bookmarkable URL. But what does that help me with? I mean -
how does that get into the place of what a link renders to the
JSF-page output? Or is that only meant to be used for redirects?
regards,
Martin
On 1/28/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> On 1/27/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> Hi Gary,
>
> > The basic idea creates a convention in the url for invoking the method.
> > contextroot/dynamic/remoting$business/cityAndStateForZip.faces?zip=80124
>
> Right it's all about naming conventions :-)
>
> I looked a Business.java's cityAndStateForZip() method.
> I don't like the parameter lookup by ExternalContext inside of a backing bean
> That is equal to let your backing bean construktor handle that
> parameter stuff...
>
> I played during my train travel with somesthing similar.
> A given url:
>
> host/app/bookmark/test.faces?foo=HALLO&bar=moin
>
> > A phase listener intercepts "dynamic" folder as the special identifier.
> > Next comes the managed bean name and then the method.
>
> right. my phase listener intercepts "bookmark". I strip "/bookmark"
> from viewId, so I set it to "/test.jsp" (in this case)
>
> I also have (like Shale's view controller) the convention that "test"
> is the name of my backing bean bean
>
> (yes, something like
>
> host/app/bookmark/folder/test.faces?foo=HALLO&bar=moin
>
> will look for a "viewController named folder$test)
>
> Now the phase listener has the convention, that "foo" and "bar" are
> the bean properties
> and populates the bean with the given values.
>
> Of course, this is a first shot. May be it is to restrictive? However,
> let's see :-)
>
> PS: code is attached... because I am away from my *real* box, (had to
> use a usb stick to upload the file :-))
>
> For Rendering the bookmarkable URL, I liked Adam's (or John's ;))
> suggestion with the optional interface for the NavigationHandler
>
> -Matthias
>
>
> /*
> * Copyright 2006 The Apache Software Foundation.
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> * You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> package net.wessendorf.faces.bookmark;
>
> import java.util.Iterator;
> import java.util.Map;
> import java.util.Set;
>
> import javax.faces.application.ViewHandler;
> import javax.faces.context.FacesContext;
> import javax.faces.el.ValueBinding;
> import javax.faces.event.PhaseEvent;
> import javax.faces.event.PhaseId;
> import javax.faces.event.PhaseListener;
>
> import org.apache.commons.lang.StringUtils;
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> /**
> *
> * @author matzew
> *
> */
> public class BookmarkPhaseListener implements PhaseListener {
>
> private static final Log log =
> LogFactory.getLog(BookmarkPhaseListener.class);
>
> public static String BOOKMARK = "/bookmark";
>
> private static final long serialVersionUID = 1L;
>
> public void afterPhase(PhaseEvent event) {
> FacesContext facesContext = event.getFacesContext();
>
> if(facesContext.getViewRoot().getViewId().startsWith(BOOKMARK))
> invokeApplication(facesContext);
> }
>
> public void invokeApplication(FacesContext facesContext) {
> String oldViewId = facesContext.getViewRoot().getViewId();
> if(log.isTraceEnabled())
> log.trace("Incomming view id: " + oldViewId);
> String newViewId = oldViewId.substring(BOOKMARK.length());
> facesContext.getViewRoot().setViewId(newViewId);
> if(log.isTraceEnabled())
> log.trace("new generated view id: " + newViewId);
>
> Map parameters =
> facesContext.getExternalContext().getRequestParameterMap();
> Set keys = parameters.keySet();
> ValueBinding vb = null;
> String beanName = extractViewControllerName(newViewId);
> if(!parameters.isEmpty()){
>
> for(Iterator it = keys.iterator(); it.hasN
Re: Bookmarking, History and JSF
On 1/27/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
Hi Gary,
> The basic idea creates a convention in the url for invoking the method.
> contextroot/dynamic/remoting$business/cityAndStateForZip.faces?zip=80124
Right it's all about naming conventions :-)
I looked a Business.java's cityAndStateForZip() method.
I don't like the parameter lookup by ExternalContext inside of a backing bean
That is equal to let your backing bean construktor handle that
parameter stuff...
I played during my train travel with somesthing similar.
A given url:
host/app/bookmark/test.faces?foo=HALLO&bar=moin
> A phase listener intercepts "dynamic" folder as the special identifier.
> Next comes the managed bean name and then the method.
right. my phase listener intercepts "bookmark". I strip "/bookmark"
from viewId, so I set it to "/test.jsp" (in this case)
I also have (like Shale's view controller) the convention that "test"
is the name of my backing bean bean
(yes, something like
host/app/bookmark/folder/test.faces?foo=HALLO&bar=moin
will look for a "viewController named folder$test)
Now the phase listener has the convention, that "foo" and "bar" are
the bean properties
and populates the bean with the given values.
Of course, this is a first shot. May be it is to restrictive? However,
let's see :-)
PS: code is attached... because I am away from my *real* box, (had to
use a usb stick to upload the file :-))
For Rendering the bookmarkable URL, I liked Adam's (or John's ;))
suggestion with the optional interface for the NavigationHandler
-Matthias
/*
* Copyright 2006 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package net.wessendorf.faces.bookmark;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import javax.faces.application.ViewHandler;
import javax.faces.context.FacesContext;
import javax.faces.el.ValueBinding;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import org.apache.commons.lang.StringUtils;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
*
* @author matzew
*
*/
public class BookmarkPhaseListener implements PhaseListener {
private static final Log log =
LogFactory.getLog(BookmarkPhaseListener.class);
public static String BOOKMARK = "/bookmark";
private static final long serialVersionUID = 1L;
public void afterPhase(PhaseEvent event) {
FacesContext facesContext = event.getFacesContext();
if(facesContext.getViewRoot().getViewId().startsWith(BOOKMARK))
invokeApplication(facesContext);
}
public void invokeApplication(FacesContext facesContext) {
String oldViewId = facesContext.getViewRoot().getViewId();
if(log.isTraceEnabled())
log.trace("Incomming view id: " + oldViewId);
String newViewId = oldViewId.substring(BOOKMARK.length());
facesContext.getViewRoot().setViewId(newViewId);
if(log.isTraceEnabled())
log.trace("new generated view id: " + newViewId);
Map parameters =
facesContext.getExternalContext().getRequestParameterMap();
Set keys = parameters.keySet();
ValueBinding vb = null;
String beanName = extractViewControllerName(newViewId);
if(!parameters.isEmpty()){
for(Iterator it = keys.iterator(); it.hasNext();){
String key = it.next().toString();
if(log.isTraceEnabled())
log.trace("Looking for vb: " +
"#{" + beanName + "." + key + "}");
vb =
facesContext.getApplication().createValueBinding("#{" +
beanName + "." + key + "}");
vb.setValue(facesContext, parameters.get(key));
}
}
}
private String extractViewControllerName(String newViewId) {
String extract = newViewId.substring(1);
extract =
extract.substring(0,extract.indexOf(ViewHandler.DEFAULT_SUFFIX));
if(StringUtils.contains(extract, "/")){
extract = StringUtils.replace(extract, "/", "$");
}
RE: RE: Bookmarking, History and JSF
I think we are talking about solving different issues here:
1) FacesRequest->Action->Non-FacesRequest
Could be handled by the NavigationHandler via EL for parameter passing on
redirects (a Non-FacesRequest) [/user.jsf?id=3433]
2) ???->Non-FacesRequest
Could be handled below with a special view handler, that works just like
WebWork/RoR, but then you carry all of the baggage with exposing your model
beans to invocation/assignment over the web. Sounds great if you do separate
your actions from your model. Again, with this baggage, that's why I'm
suggesting a separate ViewHandler that piggybacks Struts 2.0 or whatever then
goes to JSF views (ala the original struts-jsf integration that Craig did)
[/user.display.action?id=3433]
--
I agree that the WebWork/RoR like parameter binding is nice, but then you are
carrying a lot more logic for what can or can't be assigned to the bean you've
just exposed over the internet. Also, this would be difficult to model for
iterative contexts (a commandLink from within UIData to a specific 'user'
within some row).
--
For the Avatar stuff, the idea is to do everything by clientId, so if you
wanted to invoke some commandLink within the target view called "foo", then you
would pass /edit.jsf?foo=X&java.faces.ViewState=[...] which would cause foo,
within the decode to see that it was fired, invoke the action it's associated
with [immediate?], and this would happen without leaking your domain model over
the internet. The java.faces.ViewState would be optional if you wanted to
pursue a stateless route within the ViewHandler using conversation ids.
-- Jacob
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> Sent: Friday, January 27, 2006 7:19 PM
>> To: dev@myfaces.apache.org; dev@myfaces.apache.org
>> Subject: Re: Bookmarking, History and JSF
>>
>> Unless I misunderstood--
>>
>> I've been saying you wouldn't want this though, because now
>> your logic is bound to some assumption of previous state--
>> where did the id come from, which is bad for GETs.
>
>Why? all we need is a mapping mechanism that connects the url to
>an action method of backing bean. All parameters are then
>mapped to attributes of this same backing bean if the names
>match. The rest is left as req-parms... the outcoming view-renderer
>is determined from the outcome of the action-method...
>
>I think no assumption of state here...
>
>regards
>Alexander
>
>>
>> You could pass the id, using EL evaluation of to-view-id,
>> allowing a (separate) view decide how and where to map that
>> #{param.id} into the succeeding request.
>>
>> -- Jacob
>>
>> >
>> >And once you'd solved this what you'd *really* want on top of this is
>> >something in the nav handler that lets you then also deal with the
>> >incoming "id" query attribute that feeds naturally back into
>> JSF component
>> >state land instead of forcing you to hardcode logic to
>> implement this.
>> >(Seam Conversations and ADF processScope come to mind.)
>> >
>> >-- Adam
>> >
>> >
>> >On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> >> That's an interesting solution-- with webwork, it allows EL (OGNL)
>> >evaluation of URIs, so across the board, we could do something like:
>> >>
>> >>
>> >> /foo.jsp
>> >>
>> >> success
>> >>
>> >> /user.jsf?id=#{user.id}
>> >>
>> >>
>> >>
>> >> Where we could now say that the resulting view-id is
>> evaluated as an
>> >expression based on the current state of the FacesContext.
>> >>
>> >> -- Jacob
>> >>
>> >> >
>> >> >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
Re: Bookmarking, History and JSF
Yes ! I have any attempts to realize of same idea, but not solve one
problem - it need extend format of faces-config or make standalone
configuration - not good
In most web-application cases we need bookmark not concrete page, but
logical part of application.
In such cases best effect will be output entry point of part ( wizard
start page, root of catalog etc ), what solved by such navigation handler
Adam Winer 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:
myTable.jspx
#{row.showRow}
/faces/showRow.jspx?id=#{row.id}
And "default-action" for GET without parameters !
... 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.
-
RE: Bookmarking, History and JSF
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 27, 2006 7:19 PM
> To: dev@myfaces.apache.org; dev@myfaces.apache.org
> Subject: Re: Bookmarking, History and JSF
>
> Unless I misunderstood--
>
> I've been saying you wouldn't want this though, because now
> your logic is bound to some assumption of previous state--
> where did the id come from, which is bad for GETs.
Why? all we need is a mapping mechanism that connects the url to
an action method of backing bean. All parameters are then
mapped to attributes of this same backing bean if the names
match. The rest is left as req-parms... the outcoming view-renderer
is determined from the outcome of the action-method...
I think no assumption of state here...
regards
Alexander
>
> You could pass the id, using EL evaluation of to-view-id,
> allowing a (separate) view decide how and where to map that
> #{param.id} into the succeeding request.
>
> -- Jacob
>
> >
> >And once you'd solved this what you'd *really* want on top of this is
> >something in the nav handler that lets you then also deal with the
> >incoming "id" query attribute that feeds naturally back into
> JSF component
> >state land instead of forcing you to hardcode logic to
> implement this.
> >(Seam Conversations and ADF processScope come to mind.)
> >
> >-- Adam
> >
> >
> >On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> That's an interesting solution-- with webwork, it allows EL (OGNL)
> >evaluation of URIs, so across the board, we could do something like:
> >>
> >>
> >> /foo.jsp
> >>
> >> success
> >>
> >> /user.jsf?id=#{user.id}
> >>
> >>
> >>
> >> Where we could now say that the resulting view-id is
> evaluated as an
> >expression based on the current state of the FacesContext.
> >>
> >> -- Jacob
> >>
> >> >
> >> >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:
> >> >
> >> > myTable.jspx
> >> > #{row.showRow}
> >> > /faces/showRow.jspx?id=#{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 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
Re: Bookmarking, History and JSF
JSF doesn't have a built-in front controller. If anything, it should be optional, but things like no DB connection are usually handled by global filters/policies and wouldn't be on a per-action basis. The additional lifecycle events that Shale introduces will also be available in JSF 1.2 with both the UIViewRoot.addPhaseListener(..) ... -- and Ed Burn's inclusion of common annotation's Destroy/Created events being handled from the managed beans in your faces-config. (again, for bookmarkable links, I do like the EL evaluation within navigation cases the best-- it's similar to WebWork) > >Martin Marinschek wrote: > >>outputLink doesn't tie into the action-framework - that's why... >> >>what's Struts-Shale doing here? outputLink with defaultAction="something"? >> >>regards, >> >>Martin >> >> >> >In struts, I can perform action for request on any ...do link not only >for submitting form, but for ANY request. >In any cases, I can display different pages - for example, Message "see >late" if application don't have connect to sql server, choise different >pages for mobile clients, output first page of continuous wizarrd etc. >For jsf, even if proposed GET processing can help bookmark page, content >can depend of previsius state of application or other conditions. >Main thing - JSF support MVC pattern for form processing, but break >controller for GET requests.
Re: Bookmarking, History and JSF
Martin Marinschek wrote: outputLink doesn't tie into the action-framework - that's why... what's Struts-Shale doing here? outputLink with defaultAction="something"? regards, Martin In struts, I can perform action for request on any ...do link not only for submitting form, but for ANY request. In any cases, I can display different pages - for example, Message "see late" if application don't have connect to sql server, choise different pages for mobile clients, output first page of continuous wizarrd etc. For jsf, even if proposed GET processing can help bookmark page, content can depend of previsius state of application or other conditions. Main thing - JSF support MVC pattern for form processing, but break controller for GET requests.
Re: Bookmarking, History and JSF
Unless I misunderstood--
I've been saying you wouldn't want this though, because now your logic is bound
to some assumption of previous state-- where did the id come from, which is bad
for GETs.
You could pass the id, using EL evaluation of to-view-id, allowing a (separate)
view decide how and where to map that #{param.id} into the succeeding request.
-- Jacob
>
>And once you'd solved this what you'd *really* want on top of this is
>something in the nav handler that lets you then also deal with the
>incoming "id" query attribute that feeds naturally back into JSF component
>state land instead of forcing you to hardcode logic to implement this.
>(Seam Conversations and ADF processScope come to mind.)
>
>-- Adam
>
>
>On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> That's an interesting solution-- with webwork, it allows EL (OGNL)
>evaluation of URIs, so across the board, we could do something like:
>>
>>
>> /foo.jsp
>>
>> success
>>
>> /user.jsf?id=#{user.id}
>>
>>
>>
>> Where we could now say that the resulting view-id is evaluated as an
>expression based on the current state of the FacesContext.
>>
>> -- Jacob
>>
>> >
>> >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:
>> >
>> > myTable.jspx
>> > #{row.showRow}
>> > /faces/showRow.jspx?id=#{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 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: 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ß 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 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
Re: Bookmarking, History and JSF
Yes, I reaaalllyyy want that as well.
Matze has already suggested that - we'll have that in our solution ;)
regards,
Martin
On 1/27/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> And once you'd solved this what you'd *really* want on top of this is
> something in the nav handler that lets you then also deal with the
> incoming "id" query attribute that feeds naturally back into JSF component
> state land instead of forcing you to hardcode logic to implement this.
> (Seam Conversations and ADF processScope come to mind.)
>
> -- Adam
>
>
> On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > That's an interesting solution-- with webwork, it allows EL (OGNL)
> > evaluation of URIs, so across the board, we could do something like:
> >
> >
> > /foo.jsp
> >
> > success
> >
> > /user.jsf?id=#{user.id}
> >
> >
> >
> > Where we could now say that the resulting view-id is evaluated as an
> > expression based on the current state of the FacesContext.
> >
> > -- Jacob
> >
> > >
> > >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:
> > >
> > > myTable.jspx
> > > #{row.showRow}
> > > /faces/showRow.jspx?id=#{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 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: 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ß 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 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
Re: Bookmarking, History and JSF
And once you'd solved this what you'd *really* want on top of this is
something in the nav handler that lets you then also deal with the
incoming "id" query attribute that feeds naturally back into JSF component
state land instead of forcing you to hardcode logic to implement this.
(Seam Conversations and ADF processScope come to mind.)
-- Adam
On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> That's an interesting solution-- with webwork, it allows EL (OGNL) evaluation
> of URIs, so across the board, we could do something like:
>
>
> /foo.jsp
>
> success
>
> /user.jsf?id=#{user.id}
>
>
>
> Where we could now say that the resulting view-id is evaluated as an
> expression based on the current state of the FacesContext.
>
> -- Jacob
>
> >
> >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:
> >
> > myTable.jspx
> > #{row.showRow}
> > /faces/showRow.jspx?id=#{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 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: 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ß 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 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 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
Re: Bookmarking, History and JSF
That only gets you about a third of the way there, since JSF isn't giving you a decent semantic way to generate meaningful GET requests in the first place. -- Adam On 1/27/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 1/27/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > outputLink doesn't tie into the action-framework - that's why... > > > > what's Struts-Shale doing here? outputLink with defaultAction="something"? > > If you use view controllers in Shale, a GET request will trigger init(), > then prerender(), then render your view, then call destroy(). Conveniently, > this is exactly the same sequence of events you get when you navigate to the > page in the usual way, so you don't have to code it any differently. > Typically, you'd put logic that sets up the data you need for rendering into > the prerender() method, which you can think of (in Struts terms) as a "setup > action". > > > regards, > > > > Martin > > Craig > >
Re: Bookmarking, History and JSF
On 1/27/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: outputLink doesn't tie into the action-framework - that's why...what's Struts-Shale doing here? outputLink with defaultAction="something"?If you use view controllers in Shale, a GET request will trigger init(), then prerender(), then render your view, then call destroy(). Conveniently, this is exactly the same sequence of events you get when you navigate to the page in the usual way, so you don't have to code it any differently. Typically, you'd put logic that sets up the data you need for rendering into the prerender() method, which you can think of (in Struts terms) as a "setup action". regards,MartinCraig
Re: Bookmarking, History and JSF
That's an interesting solution-- with webwork, it allows EL (OGNL) evaluation
of URIs, so across the board, we could do something like:
/foo.jsp
success
/user.jsf?id=#{user.id}
Where we could now say that the resulting view-id is evaluated as an expression
based on the current state of the FacesContext.
-- Jacob
>
>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:
>
> myTable.jspx
> #{row.showRow}
> /faces/showRow.jspx?id=#{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 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: 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ß 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 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 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 d
Re: Re: Bookmarking, History and JSF
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:
>
> myTable.jspx
>#{row.showRow}
>/faces/showRow.jspx?id=#{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 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: 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ß 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 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 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
Re: Re: Bookmarking, History and JSF
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:
myTable.jspx
#{row.showRow}
/faces/showRow.jspx?id=#{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 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: 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ß 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 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 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]
> >
>
Re: Bookmarking, History and JSF
Hi Werner, You're absolutely right. My "could" actually meant we must ;) What we do though would be to automatically fail-over to normal state-saving and rendering, if the state grows too large. So we have an error, right, but the app doesn't stop working. The page just isn't bookmarkable anymore. regards, Martin On 1/27/06, Werner Punz <[EMAIL PROTECTED]> wrote: > Martin Marinschek schrieb: > > We could optionally do that - don't know if that is practical. > > > > I've discussed with Manfred some more, and he suggests to do the following: > > > > give t:saveState an optional "bookmarkable"=true attribute, and with > > that decide on some of the state to be saved even though the > > tree-state is lost. > > > > we could also log an error to the user when the maximum url-size is > > exceeded. > > > > That error is definitely mandatory to avoid constant posts in the users > list why data gets lost ;-) > No in fact the size limitation is one of the reasons post usually is > preferred for form handling, such an error would help alot in a get > situation to track down problems. > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Re: Re: Bookmarking, History and JSF
Hi Jacob, Seam's state-saving method is server-side, right? The conversation will be stored on the server? Is that a persistent storage - in the sense of a database, or a volatile storage - in the sense of a server session (ok, I know, server side sessions can be persisted, too;) ? option 1) So if you write the state-id down to the client and the conversation goes out of scope on the server, the reference would be lost, right? option 2) if the server-side state is something actually being persisted, then if you really persist every state any user had interacting with your system, you'll need some really cool hardware stuff for your webapp... and bookmarkable means you'll need to save the state for a really long time ;) See, my 2c, the thing is that we need client-side state saving here. We won't be able to store the million states we might get from our user-requests neither into the server memory nor a database. We need client-side state saving it (and if you want it bookmarkable, also URL based client-side state), and we need to restrict the size of the state to something usable. And this is where t:saveState comes in handy. So what I propose is a mixture: you have server-side (or form based client-side state saving) for the normal, highly stateful webapp stuff you do, and use client-side state saving in the URL for everything that is publicly accessible, needs to be bookmarked and has a very small state-footprint. regards, Martin On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Yeah, that's correct, who says ViewState actually has to be your component > model? :-) > > I've thought about progressing the stateless JSF solution to instead just > write Seam's converstation ID as the ViewState (a numeric long) to match up > to model state. This kind of solution makes a lot more sense than retaining > the component model between requests. It would be similar to t:saveState, > but is a little more natural for the view/model separation. > > -- Jacob > > > > >Hi Jacob, > > > >yes, but I'm talking about being able to pass _some_ state here. So > >you don't go fully stateless, you have the ability to reduce the state > >to a size where it is usable with GET-Requests. > > > >And I want to use MyFaces t:saveState feature for providing this > >ability. Together with an error to tell you if your state has grown > >too large, this is something that might be usable in many cases where > >full state just doesn't work. > > > >regards, > > > >Martin > > > >On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> If you want to go minimal/stateless with JSF, it's somewhat do-able. I was > >able to take a sandbox of Facelets and simply: > >> > >> 1) Always write an empty hidden input param for 'javax.faces.ViewState' to > >get the succeeding request to expect a Restored View > >> > >> 2) Within ViewHandler.restoreView(..) call createView(..) and actually > >populate it before the decode phase so parameters/state can be operated on. > >> > >> 3) On render, don't bother saving state, but pass the view-root for > >re-building to update the tree state for rendering again. > >> > >> I was able to get things using UIData, like the notorious Hangman demo > >working with the above implementation. It would break, of course, for > >components that expected retained state across calls, but the declarative > >nature of component use and the proper view/model separation via EL makes > >this > >very practical. > >> > >> Basically, all components have a request-scoped lifecycle instead of a > >session one as they exist now. Performance wise, there wasn't much change > >(20-30ms better w/ request-scoped). > >> > >> -- Jacob > >> > >> > > >> >As Ed noted, saving everything into the GET request does not work > >> >because of URL size limitations. Old stagers within the MyFaces > >> >community might remember the so called "minimizing state" feature in > >> >early MyFaces 0.x versions. The goal was to provide a JSF > >> >implementation that works without JavaScript AND without Servlet > >> >sessions. > >> >Well, as you know, we gave up the idea of saving everything to the > >> >URL. It's simply unsolvable AFAICT. > >> > > >> >What Martin proposes is a rather simple solution that - of course - > >> >breaks normal JSF lifecycle, but could be a good solution for the > >> >ordinary webapp. Most bookmarkable pages are those that you can reach > >> >via a navigation menu or alike. Not much state information needed in > >> >most of these cases. What important information do we need when a user > >> >comes back to a "menu linked" page via bookmark? > >> >- the logged in user: we get him from the JASS authentication if we are > >lucky > >> >- some kind of id (product id or things like that): it's part of the > >> >URL if we use the bookmarkable feature of the t:safeState tag > >> >- more? > >> > > >> >This is no all-out-of-the-box solution, but I think it's worth playing > >> >around a little bit with this soluti
Re: Bookmarking, History and JSF
>How do you explain the user that he's using actions all over the >application, and then for his GET needs, he has to provide an url with >parameters and other stuff? I don't think it's confusing at all. If anything, I would suggest something like Craig has been bringing up where the requested URI *is* an action, nothing parameter based (as suggested by exadel). In any case, you would still be in the same boat of having alternate methods of invoking actions which is extremely confusing. >From a front controller aspect (which is what you are describing), 90% of >people's needs are handled by filters or global error policies. Its a niche >case where you would want to display a completely different view based on >action invocation within the front controller in a GET request. Again, a user >can sit there and hit refresh and keep on invoking that GET request, maybe in >a draconic sense, JSF is preventing users from doing things they shouldn't be. In my mind, a bookmarkable link should just be /user.jsf?id=433, let login and error filters handle assertions over the URI outside of JSF's action controller. If you need to execute some behavior, such as a fetch, then use JSF 1.2's phase listeners that are attachable to the UIViewRoot. -- Jacob > >Well, > >I think you have to distinct clearly here. The concept of "actions" >which lead to somewhere else is a somewhat widely used concept in >web-applications. If you don't call dynamic method-bindings, but you >have static action-references, I don't think that you can lump >together calling actions and saving state. > >I don't see why we force on our users to learn actions first - and >then don't allow them to use these actions for doing get-requests as >well. That ought to be possible, really. >How do you explain the user that he's using actions all over the >application, and then for his GET needs, he has to provide an url with >parameters and other stuff? > >How does solving this issue break POST vs. GET? > >We are making it clear to the user that something differently happens >here if he uses a bookmarkable link. > >regards, > >Martin > > >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: 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ß 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 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 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 t
Re: Re: Bookmarking, History and JSF
>From: Martin Marinschek <[EMAIL PROTECTED]> >> Hi Jacob, > > yes, but I'm talking about being able to pass _some_ state here. So > you don't go fully stateless, you have the ability to reduce the state > to a size where it is usable with GET-Requests. > I agree with you Martin. Why not burn\generate a token that has special meaning to the life cycle from the component API that could be added as query parameter? It would be a special pass that would allow a GET request to continue on. This would assume that you already had state server side where the token was generated. Why should JSF be discounted for companies that have strict accessibility standards prohibiting _javascript_ for navigation? > And I want to use MyFaces t:saveState feature for providing this > ability. Together with an error to tell you if your state has grown > too large, this is something that might be usable in many cases where > full state just doesn't work. > > regards, > > Martin > > On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>wrote: > > If you want to go minimal/stateless with JSF, it's somewhat do-able. I was > able to take a sandbox of Facelets and simply: > > > > 1) Always write an empty hidden input param for 'javax.faces.ViewState' to get > the succeeding request to expect a Restored View > > > > 2) Within ViewHandler.restoreView(..) call createView(..) and actually > populate it before the decode phase so parameters/state can be operated on. > > > > 3) On render, don't bother saving state, but pass the view-root for &g t; re-building to update the tree state for rendering again. > > > > I was able to get things using UIData, like the notorious Hangman demo working > with the above implementation. It would break, of course, for components that > expected retained state across calls, but the declarative nature of component > use and the proper view/model separation via EL makes this very practical. > > > > Basically, all components have a request-scoped lifecycle instead of a session > one as they exist now. Performance wise, there wasn't much change (20-30ms > better w/ request-scoped). > > > > -- Jacob > > > > > > > >As Ed noted, saving everything into the GET request does not work > > >because of URL size limitations. Old stagers within the MyFaces > > >community might remember the so called "minimizing state" feature in > > >early MyFaces 0.x versions. The goal was to provide a JSF > > >implementation that works without _javascript_ AND without Servlet > > >sessions. > > >Well, as you know, we gave up the idea of saving everything to the > > >URL. It's simply unsolvable AFAICT. > > > > > >What Martin proposes is a rather simple solution that - of course - > > >breaks normal JSF lifecycle, but could be a good solution for the > > >ordinary webapp. Most bookmarkable pages are those that you can reach > > >via a navigation menu or alike. Not much state information needed in > > >most of these cases. What important information do we need when a user > > >comes back to a "menu linked" page via bookmark? > > >- the logged in user: we get him from the JASS authentication if we are lucky > > >- some kind of id (product id or things li ke that): it's part of the > > >URL if we use the bookmarkable feature of the t:safeState tag > > >- more? > > > > > >This is no all-out-of-the-box solution, but I think it's worth playing > > >around a little bit with this solution. > > > > > >+1 for Martins proposal - give it a shot > > > > > >Manfred > > > > > > > > > > > > > > >2006/1/27, Ed Burns <[EMAIL PROTECTED]>: > > >> 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 ;) > > &g t;> 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? > & gt; >> 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
Re: Bookmarking, History and JSF
Martin Marinschek schrieb: We could optionally do that - don't know if that is practical. I've discussed with Manfred some more, and he suggests to do the following: give t:saveState an optional "bookmarkable"=true attribute, and with that decide on some of the state to be saved even though the tree-state is lost. we could also log an error to the user when the maximum url-size is exceeded. That error is definitely mandatory to avoid constant posts in the users list why data gets lost ;-) No in fact the size limitation is one of the reasons post usually is preferred for form handling, such an error would help alot in a get situation to track down problems.
RE: Re: Re: Bookmarking, History and JSF
Yeah, that's correct, who says ViewState actually has to be your component model? :-) I've thought about progressing the stateless JSF solution to instead just write Seam's converstation ID as the ViewState (a numeric long) to match up to model state. This kind of solution makes a lot more sense than retaining the component model between requests. It would be similar to t:saveState, but is a little more natural for the view/model separation. -- Jacob > >Hi Jacob, > >yes, but I'm talking about being able to pass _some_ state here. So >you don't go fully stateless, you have the ability to reduce the state >to a size where it is usable with GET-Requests. > >And I want to use MyFaces t:saveState feature for providing this >ability. Together with an error to tell you if your state has grown >too large, this is something that might be usable in many cases where >full state just doesn't work. > >regards, > >Martin > >On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> If you want to go minimal/stateless with JSF, it's somewhat do-able. I was >able to take a sandbox of Facelets and simply: >> >> 1) Always write an empty hidden input param for 'javax.faces.ViewState' to >get the succeeding request to expect a Restored View >> >> 2) Within ViewHandler.restoreView(..) call createView(..) and actually >populate it before the decode phase so parameters/state can be operated on. >> >> 3) On render, don't bother saving state, but pass the view-root for >re-building to update the tree state for rendering again. >> >> I was able to get things using UIData, like the notorious Hangman demo >working with the above implementation. It would break, of course, for >components that expected retained state across calls, but the declarative >nature of component use and the proper view/model separation via EL makes this >very practical. >> >> Basically, all components have a request-scoped lifecycle instead of a >session one as they exist now. Performance wise, there wasn't much change >(20-30ms better w/ request-scoped). >> >> -- Jacob >> >> > >> >As Ed noted, saving everything into the GET request does not work >> >because of URL size limitations. Old stagers within the MyFaces >> >community might remember the so called "minimizing state" feature in >> >early MyFaces 0.x versions. The goal was to provide a JSF >> >implementation that works without JavaScript AND without Servlet >> >sessions. >> >Well, as you know, we gave up the idea of saving everything to the >> >URL. It's simply unsolvable AFAICT. >> > >> >What Martin proposes is a rather simple solution that - of course - >> >breaks normal JSF lifecycle, but could be a good solution for the >> >ordinary webapp. Most bookmarkable pages are those that you can reach >> >via a navigation menu or alike. Not much state information needed in >> >most of these cases. What important information do we need when a user >> >comes back to a "menu linked" page via bookmark? >> >- the logged in user: we get him from the JASS authentication if we are >lucky >> >- some kind of id (product id or things like that): it's part of the >> >URL if we use the bookmarkable feature of the t:safeState tag >> >- more? >> > >> >This is no all-out-of-the-box solution, but I think it's worth playing >> >around a little bit with this solution. >> > >> >+1 for Martins proposal - give it a shot >> > >> >Manfred >> > >> > >> > >> > >> >2006/1/27, Ed Burns <[EMAIL PROTECTED]>: >> >> 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 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 we even >> >> have an issue on our issue tracker for it: >> >> >> >> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=72 >> >> >> >> MM> E
Re: Bookmarking, History and JSF
Hi Ed,
danke, in Wien geht's hervorragend ;)
you're right, of course. This has to be clearly documented. And
indeed, this problem is unsolvable. Manfred has invested a lot of work
into MyFaces trying to get this to run somehow by further minimizing
the state - but with the restrictions imposed by IE, this is clearly
undoable currently.
Still, the users obviously want something like this - me personally, I
don't care too much, I don't need it for my high-secure
banking-finance closed to the world applications ;)
And I do think they can live with the trade-off, here.
regards,
Martin
On 1/27/06, Ed Burns <[EMAIL PROTECTED]> wrote:
> Hallo Manolito,
>
> Wie geht es in Wien?
>
> > On Fri, 27 Jan 2006 16:06:26 +0100, Manfred Geiler <[EMAIL PROTECTED]>
> > said:
>
> MG> As Ed noted, saving everything into the GET request does not work
> MG> because of URL size limitations. Old stagers within the MyFaces
> MG> community might remember the so called "minimizing state" feature in
> MG> early MyFaces 0.x versions. The goal was to provide a JSF
> MG> implementation that works without JavaScript AND without Servlet
> MG> sessions.
> MG> Well, as you know, we gave up the idea of saving everything to the
> MG> URL. It's simply unsolvable AFAICT.
>
> MG> What Martin proposes is a rather simple solution that - of course -
> MG> breaks normal JSF lifecycle, but could be a good solution for the
> MG> ordinary webapp. Most bookmarkable pages are those that you can reach
> MG> via a navigation menu or alike. Not much state information needed in
> MG> most of these cases. What important information do we need when a user
> MG> comes back to a "menu linked" page via bookmark?
> MG> - the logged in user: we get him from the JASS authentication if we are
> lucky
> MG> - some kind of id (product id or things like that): it's part of the
> MG> URL if we use the bookmarkable feature of the t:safeState tag
> MG> - more?
>
> MG> This is no all-out-of-the-box solution, but I think it's worth playing
> MG> around a little bit with this solution.
>
> MG> +1 for Martins proposal - give it a shot
>
> Just make sure the limitations are well understood and clearly
> documented. I wouldn't want people thinking that MyFaces has a solution
> to an unsolvable (or at least really hard and inelegant) problem when
> really it doesn't :). This is a meritocracy after all!
>
> 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://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
Hallo Manolito,
Wie geht es in Wien?
> On Fri, 27 Jan 2006 16:06:26 +0100, Manfred Geiler <[EMAIL PROTECTED]>
> said:
MG> As Ed noted, saving everything into the GET request does not work
MG> because of URL size limitations. Old stagers within the MyFaces
MG> community might remember the so called "minimizing state" feature in
MG> early MyFaces 0.x versions. The goal was to provide a JSF
MG> implementation that works without JavaScript AND without Servlet
MG> sessions.
MG> Well, as you know, we gave up the idea of saving everything to the
MG> URL. It's simply unsolvable AFAICT.
MG> What Martin proposes is a rather simple solution that - of course -
MG> breaks normal JSF lifecycle, but could be a good solution for the
MG> ordinary webapp. Most bookmarkable pages are those that you can reach
MG> via a navigation menu or alike. Not much state information needed in
MG> most of these cases. What important information do we need when a user
MG> comes back to a "menu linked" page via bookmark?
MG> - the logged in user: we get him from the JASS authentication if we are
lucky
MG> - some kind of id (product id or things like that): it's part of the
MG> URL if we use the bookmarkable feature of the t:safeState tag
MG> - more?
MG> This is no all-out-of-the-box solution, but I think it's worth playing
MG> around a little bit with this solution.
MG> +1 for Martins proposal - give it a shot
Just make sure the limitations are well understood and clearly
documented. I wouldn't want people thinking that MyFaces has a solution
to an unsolvable (or at least really hard and inelegant) problem when
really it doesn't :). This is a meritocracy after all!
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]
Re: Re: Bookmarking, History and JSF
Hi Jacob, yes, but I'm talking about being able to pass _some_ state here. So you don't go fully stateless, you have the ability to reduce the state to a size where it is usable with GET-Requests. And I want to use MyFaces t:saveState feature for providing this ability. Together with an error to tell you if your state has grown too large, this is something that might be usable in many cases where full state just doesn't work. regards, Martin On 1/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > If you want to go minimal/stateless with JSF, it's somewhat do-able. I was > able to take a sandbox of Facelets and simply: > > 1) Always write an empty hidden input param for 'javax.faces.ViewState' to > get the succeeding request to expect a Restored View > > 2) Within ViewHandler.restoreView(..) call createView(..) and actually > populate it before the decode phase so parameters/state can be operated on. > > 3) On render, don't bother saving state, but pass the view-root for > re-building to update the tree state for rendering again. > > I was able to get things using UIData, like the notorious Hangman demo > working with the above implementation. It would break, of course, for > components that expected retained state across calls, but the declarative > nature of component use and the proper view/model separation via EL makes > this very practical. > > Basically, all components have a request-scoped lifecycle instead of a > session one as they exist now. Performance wise, there wasn't much change > (20-30ms better w/ request-scoped). > > -- Jacob > > > > >As Ed noted, saving everything into the GET request does not work > >because of URL size limitations. Old stagers within the MyFaces > >community might remember the so called "minimizing state" feature in > >early MyFaces 0.x versions. The goal was to provide a JSF > >implementation that works without JavaScript AND without Servlet > >sessions. > >Well, as you know, we gave up the idea of saving everything to the > >URL. It's simply unsolvable AFAICT. > > > >What Martin proposes is a rather simple solution that - of course - > >breaks normal JSF lifecycle, but could be a good solution for the > >ordinary webapp. Most bookmarkable pages are those that you can reach > >via a navigation menu or alike. Not much state information needed in > >most of these cases. What important information do we need when a user > >comes back to a "menu linked" page via bookmark? > >- the logged in user: we get him from the JASS authentication if we are lucky > >- some kind of id (product id or things like that): it's part of the > >URL if we use the bookmarkable feature of the t:safeState tag > >- more? > > > >This is no all-out-of-the-box solution, but I think it's worth playing > >around a little bit with this solution. > > > >+1 for Martins proposal - give it a shot > > > >Manfred > > > > > > > > > >2006/1/27, Ed Burns <[EMAIL PROTECTED]>: > >> 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 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 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 > >>
Re: Re: Bookmarking, History and JSF
Well,
I think you have to distinct clearly here. The concept of "actions"
which lead to somewhere else is a somewhat widely used concept in
web-applications. If you don't call dynamic method-bindings, but you
have static action-references, I don't think that you can lump
together calling actions and saving state.
I don't see why we force on our users to learn actions first - and
then don't allow them to use these actions for doing get-requests as
well. That ought to be possible, really.
How do you explain the user that he's using actions all over the
application, and then for his GET needs, he has to provide an url with
parameters and other stuff?
How does solving this issue break POST vs. GET?
We are making it clear to the user that something differently happens
here if he uses a bookmarkable link.
regards,
Martin
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: 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ß 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 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 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://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
>From: Matthias Wessendorf <[EMAIL PROTECTED]> >> Hi > > > Now, what do I want to be able to see in my history or to bookmark? I > > want to bookmark simple pages, where state is not so important at all. > > Or only a small portion of the state is important... > > > Those simple pages I usually refer to with an "action" attribute that > > is put (as a string) directly on the or > > tag, right? > > right, since no *complicated* calculation for action outcome is needed. > > > Why not render out this action attribute as a parameter to the URL of > > the link optionally, not submitting a form and loosing all JSF state, > > but having a bookmarkable link? > > a feature like this makes it more easier to implement systems like ebay, > where bookmarkable URLs are a must! > This is something that I've been thinking about also. Craig has a remoting solution in Shale that allows you to invoke an "action" method on a backing bean. Its purpose is for AJAX calls but I'm thinking that it might also be a way to implement bookmarkable URLs. The basic idea creates a convention in the url for invoking the method. contextroot/dynamic/remoting$business/cityAndStateForZip.faces?zip=80124 A phase listener intercepts "dynamic" folder as the special identifier. Next comes the managed bean name and then the method. His solution completes the response returning markup but I wonder if you could somehow add the target view id and create the view. Now the Shale view controller would give you processing hooks but what if you wanted to create a custom component that needed to be script less. Gary > > > > The developer can decide then: > > - do I need this link to be bookmarked > > - do I want this link to use the plain old JSF posting system with > > state-saving. > > ok > > > > > Enhancement: we could additionally render out params to this link as - > > yes, right, params to the URL. So people can optionally build there > > web-apps just like they were used to when JSF wasn't around. > > so something like > > host/app/foo.faces?param1=foo¶m2=bar > > > > > Good idea - bad idea - better idea ;) ? > > Why not rendering a link to a NonFacesRequestServlet ? > (like the tobago stuff) > > For links like > foo.faces?param1=foo¶m2=bar > > your backing bean construktor (or init() of ViewController) needs to > perform some lookups. > That could be easily done by that mentioned servlet, without doing > that parameter catching stuff inside of your backing bean. > > @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs > plan for enabling bookmarkable URLs ? > > -Matthias > > > regards, > > > > Martin > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > > > -- > Matthias Wessendorf > Zülpicher Wall 12, 239 > 50674 Köln > http://www.wessendorf.net > mwessendorf-at-gmail-dot-com
RE: Re: Bookmarking, History and JSF
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: 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ß 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 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 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]
>
RE: Re: Bookmarking, History and JSF
If you want to go minimal/stateless with JSF, it's somewhat do-able. I was
able to take a sandbox of Facelets and simply:
1) Always write an empty hidden input param for 'javax.faces.ViewState' to get
the succeeding request to expect a Restored View
2) Within ViewHandler.restoreView(..) call createView(..) and actually populate
it before the decode phase so parameters/state can be operated on.
3) On render, don't bother saving state, but pass the view-root for re-building
to update the tree state for rendering again.
I was able to get things using UIData, like the notorious Hangman demo working
with the above implementation. It would break, of course, for components that
expected retained state across calls, but the declarative nature of component
use and the proper view/model separation via EL makes this very practical.
Basically, all components have a request-scoped lifecycle instead of a session
one as they exist now. Performance wise, there wasn't much change (20-30ms
better w/ request-scoped).
-- Jacob
>
>As Ed noted, saving everything into the GET request does not work
>because of URL size limitations. Old stagers within the MyFaces
>community might remember the so called "minimizing state" feature in
>early MyFaces 0.x versions. The goal was to provide a JSF
>implementation that works without JavaScript AND without Servlet
>sessions.
>Well, as you know, we gave up the idea of saving everything to the
>URL. It's simply unsolvable AFAICT.
>
>What Martin proposes is a rather simple solution that - of course -
>breaks normal JSF lifecycle, but could be a good solution for the
>ordinary webapp. Most bookmarkable pages are those that you can reach
>via a navigation menu or alike. Not much state information needed in
>most of these cases. What important information do we need when a user
>comes back to a "menu linked" page via bookmark?
>- the logged in user: we get him from the JASS authentication if we are lucky
>- some kind of id (product id or things like that): it's part of the
>URL if we use the bookmarkable feature of the t:safeState tag
>- more?
>
>This is no all-out-of-the-box solution, but I think it's worth playing
>around a little bit with this solution.
>
>+1 for Martins proposal - give it a shot
>
>Manfred
>
>
>
>
>2006/1/27, Ed Burns <[EMAIL PROTECTED]>:
>> 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 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 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]
>>
>>
Re: Bookmarking, History and JSF
As Ed noted, saving everything into the GET request does not work
because of URL size limitations. Old stagers within the MyFaces
community might remember the so called "minimizing state" feature in
early MyFaces 0.x versions. The goal was to provide a JSF
implementation that works without JavaScript AND without Servlet
sessions.
Well, as you know, we gave up the idea of saving everything to the
URL. It's simply unsolvable AFAICT.
What Martin proposes is a rather simple solution that - of course -
breaks normal JSF lifecycle, but could be a good solution for the
ordinary webapp. Most bookmarkable pages are those that you can reach
via a navigation menu or alike. Not much state information needed in
most of these cases. What important information do we need when a user
comes back to a "menu linked" page via bookmark?
- the logged in user: we get him from the JASS authentication if we are lucky
- some kind of id (product id or things like that): it's part of the
URL if we use the bookmarkable feature of the t:safeState tag
- more?
This is no all-out-of-the-box solution, but I think it's worth playing
around a little bit with this solution.
+1 for Martins proposal - give it a shot
Manfred
2006/1/27, Ed Burns <[EMAIL PROTECTED]>:
> 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 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 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]
>
>
Re: Bookmarking, History and JSF
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 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 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]
RE: Bookmarking, History and JSF
> > @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs > plan for enabling bookmarkable URLs ? > Somebody can check for the id (url) of this ticket (being in a workshop I have limited online-possibilities ;-) regards Alexander
Re: Bookmarking, History and JSF
outputLink doesn't tie into the action-framework - that's why... what's Struts-Shale doing here? outputLink with defaultAction="something"? regards, Martin On 1/27/06, Alexander Smirnov <[EMAIL PROTECTED]> wrote: > Due to navigation caases, you page after GET request may be different > from request to request, depend on application state. For bookmarkable > links, best case to use redirect navigation options . > May be, for such cases best solution will be save/restore request state > for redirect, simulate single request processing for redirects ? After > such processing, You will have right ( bookmarkable ) uri in browser for > page. > Second part for such solution can be ability for define "default" action > methods for non-faces requested pages. In such, when re-visiting > bookmarked page, in case of non-actual page client can be forward to > different view ( as I see, such functions exist in Struts/Shale ). > > " not submitting a form and loosing all JSF state but having a > bookmarkable link? " - already exist in with nested > > > Jesse Alexander (KBSA 21) : > > to put it in a nutshell: > > > > add GET-processing to JSF... > > > > +100 ;-) > > > > regards > > Alexander > > > > -Original Message----- > > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 27, 2006 10:35 AM > > To: MyFaces Development > > Subject: Bookmarking, History and JSF > > > > Hi all, > > > > I'm having ideas again. Must come from too much work with JSF ;) > > > > My idea: > > > > Bookmarking is a problem with JSF, right? Except you use h:outputLink, > > but then there's this slight problem with not being in the action > > system anymore ;) > > > > Now, what do I want to be able to see in my history or to bookmark? I > > want to bookmark simple pages, where state is not so important at all. > > Or only a small portion of the state is important... > > > > Those simple pages I usually refer to with an "action" attribute that > > is put (as a string) directly on the or > > tag, right? > > > > Why not render out this action attribute as a parameter to the URL of > > the link optionally, not submitting a form and loosing all JSF state, > > but having a bookmarkable link? > > > > The developer can decide then: > > - do I need this link to be bookmarked > > - do I want this link to use the plain old JSF posting system with > > state-saving. > > > > Enhancement: we could additionally render out params to this link as - > > yes, right, params to the URL. So people can optionally build there > > web-apps just like they were used to when JSF wasn't around. > > > > Good idea - bad idea - better idea ;) ? > > > > regards, > > > > Martin > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > -- > Alexander Smirnov > Software developer > Exadel Inc. > http://www.exadel.com/ > mail-to:[EMAIL PROTECTED] > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
D'accord with Jamie on this. regards, Martin On 1/27/06, Cash, Jamie <[EMAIL PROTECTED]> wrote: > If a action resolves to a jsp page and not a method on a backing bean, then > there can only be one consequence of that action. > > In this case, and this case only, it would be useful for faces to render the > link as a outputLink by computing the full URL. > > The page designer, on the other hand should be able to code the links as > commandLinks. > > With this solution, all actions that can resolve to a single possible > consequence, will link to a page that will be bookmarkable. These links will > be listed in the HTML, and will therefore be followed by search engine robots. > > Regards > > Jamie > > -Original Message- > From: Alexander Smirnov [mailto:[EMAIL PROTECTED] > Sent: 27 January 2006 12:16 > To: MyFaces Development > Subject: Re: Bookmarking, History and JSF > > > Due to navigation caases, you page after GET request may be different > from request to request, depend on application state. For bookmarkable > links, best case to use redirect navigation options . > May be, for such cases best solution will be save/restore request state > for redirect, simulate single request processing for redirects ? After > such processing, You will have right ( bookmarkable ) uri in browser for > page. > Second part for such solution can be ability for define "default" action > methods for non-faces requested pages. In such, when re-visiting > bookmarked page, in case of non-actual page client can be forward to > different view ( as I see, such functions exist in Struts/Shale ). > > " not submitting a form and loosing all JSF state but having a > bookmarkable link? " - already exist in with nested > > > Jesse Alexander (KBSA 21) : > > to put it in a nutshell: > > > > add GET-processing to JSF... > > > > +100 ;-) > > > > regards > > Alexander > > > > -Original Message- > > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 27, 2006 10:35 AM > > To: MyFaces Development > > Subject: Bookmarking, History and JSF > > > > Hi all, > > > > I'm having ideas again. Must come from too much work with JSF ;) > > > > My idea: > > > > Bookmarking is a problem with JSF, right? Except you use h:outputLink, > > but then there's this slight problem with not being in the action > > system anymore ;) > > > > Now, what do I want to be able to see in my history or to bookmark? I > > want to bookmark simple pages, where state is not so important at all. > > Or only a small portion of the state is important... > > > > Those simple pages I usually refer to with an "action" attribute that > > is put (as a string) directly on the or > > tag, right? > > > > Why not render out this action attribute as a parameter to the URL of > > the link optionally, not submitting a form and loosing all JSF state, > > but having a bookmarkable link? > > > > The developer can decide then: > > - do I need this link to be bookmarked > > - do I want this link to use the plain old JSF posting system with > > state-saving. > > > > Enhancement: we could additionally render out params to this link as - > > yes, right, params to the URL. So people can optionally build there > > web-apps just like they were used to when JSF wasn't around. > > > > Good idea - bad idea - better idea ;) ? > > > > regards, > > > > Martin > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > -- > Alexander Smirnov > Software developer > Exadel Inc. > http://www.exadel.com/ > mail-to:[EMAIL PROTECTED] > > > INTERNATIONAL FINANCIAL DATA SERVICES (UK) LTD Tel: +44 1268 44 3000 > ** N O T I C E * > > This message and any attachments is intended only for the individual or > company to which it is addressed and may contain > information which is privileged, confidential or prohibited from disclosure > or unauthorised use. If the recipient of this > transmission is not the intended recipient, or the employee or agent > responsible for delivering such materials to the > intended recipient, you are hereby notified that any use, any form of > reproduction, dissemination, copying, disclosure, > modification, distribution and/or publication of this e-mai
RE: Bookmarking, History and JSF
If a action resolves to a jsp page and not a method on a backing bean, then there can only be one consequence of that action. In this case, and this case only, it would be useful for faces to render the link as a outputLink by computing the full URL. The page designer, on the other hand should be able to code the links as commandLinks. With this solution, all actions that can resolve to a single possible consequence, will link to a page that will be bookmarkable. These links will be listed in the HTML, and will therefore be followed by search engine robots. Regards Jamie -Original Message- From: Alexander Smirnov [mailto:[EMAIL PROTECTED] Sent: 27 January 2006 12:16 To: MyFaces Development Subject: Re: Bookmarking, History and JSF Due to navigation caases, you page after GET request may be different from request to request, depend on application state. For bookmarkable links, best case to use redirect navigation options . May be, for such cases best solution will be save/restore request state for redirect, simulate single request processing for redirects ? After such processing, You will have right ( bookmarkable ) uri in browser for page. Second part for such solution can be ability for define "default" action methods for non-faces requested pages. In such, when re-visiting bookmarked page, in case of non-actual page client can be forward to different view ( as I see, such functions exist in Struts/Shale ). " not submitting a form and loosing all JSF state but having a bookmarkable link? " - already exist in with nested Jesse Alexander (KBSA 21) : > to put it in a nutshell: > > add GET-processing to JSF... > > +100 ;-) > > regards > Alexander > > -Original Message- > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > Sent: Friday, January 27, 2006 10:35 AM > To: MyFaces Development > Subject: Bookmarking, History and JSF > > Hi all, > > I'm having ideas again. Must come from too much work with JSF ;) > > My idea: > > Bookmarking is a problem with JSF, right? Except you use h:outputLink, > but then there's this slight problem with not being in the action > system anymore ;) > > Now, what do I want to be able to see in my history or to bookmark? I > want to bookmark simple pages, where state is not so important at all. > Or only a small portion of the state is important... > > Those simple pages I usually refer to with an "action" attribute that > is put (as a string) directly on the or > tag, right? > > Why not render out this action attribute as a parameter to the URL of > the link optionally, not submitting a form and loosing all JSF state, > but having a bookmarkable link? > > The developer can decide then: > - do I need this link to be bookmarked > - do I want this link to use the plain old JSF posting system with > state-saving. > > Enhancement: we could additionally render out params to this link as - > yes, right, params to the URL. So people can optionally build there > web-apps just like they were used to when JSF wasn't around. > > Good idea - bad idea - better idea ;) ? > > regards, > > Martin > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces -- Alexander Smirnov Software developer Exadel Inc. http://www.exadel.com/ mail-to:[EMAIL PROTECTED] INTERNATIONAL FINANCIAL DATA SERVICES (UK) LTD Tel: +44 1268 44 3000 ** N O T I C E * This message and any attachments is intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential or prohibited from disclosure or unauthorised use. If the recipient of this transmission is not the intended recipient, or the employee or agent responsible for delivering such materials to the intended recipient, you are hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message or its attachments other than by it's intended recipient is strictly prohibited by the sender. If you have received it in error, please notify us immediately by telephone on the number above and destroy the message and all copies in your possession. International Financial Data Services (UK) Ltd is authorised and regulated by the Financial Services Authority. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **
Re: Bookmarking, History and JSF
Due to navigation caases, you page after GET request may be different from request to request, depend on application state. For bookmarkable links, best case to use redirect navigation options . May be, for such cases best solution will be save/restore request state for redirect, simulate single request processing for redirects ? After such processing, You will have right ( bookmarkable ) uri in browser for page. Second part for such solution can be ability for define "default" action methods for non-faces requested pages. In such, when re-visiting bookmarked page, in case of non-actual page client can be forward to different view ( as I see, such functions exist in Struts/Shale ). " not submitting a form and loosing all JSF state but having a bookmarkable link? " - already exist in with nested Jesse Alexander (KBSA 21) : to put it in a nutshell: add GET-processing to JSF... +100 ;-) regards Alexander -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Friday, January 27, 2006 10:35 AM To: MyFaces Development Subject: Bookmarking, History and JSF Hi all, I'm having ideas again. Must come from too much work with JSF ;) My idea: Bookmarking is a problem with JSF, right? Except you use h:outputLink, but then there's this slight problem with not being in the action system anymore ;) Now, what do I want to be able to see in my history or to bookmark? I want to bookmark simple pages, where state is not so important at all. Or only a small portion of the state is important... Those simple pages I usually refer to with an "action" attribute that is put (as a string) directly on the or tag, right? Why not render out this action attribute as a parameter to the URL of the link optionally, not submitting a form and loosing all JSF state, but having a bookmarkable link? The developer can decide then: - do I need this link to be bookmarked - do I want this link to use the plain old JSF posting system with state-saving. Enhancement: we could additionally render out params to this link as - yes, right, params to the URL. So people can optionally build there web-apps just like they were used to when JSF wasn't around. Good idea - bad idea - better idea ;) ? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Alexander Smirnov Software developer Exadel Inc. http://www.exadel.com/ mail-to:[EMAIL PROTECTED]
Re: Bookmarking, History and JSF
> Just got to make sure i understand the issue completely. > It seems that manolito has connected a few times lately as well... manolito ==> el manfredo ;) > BTW: I have a deputy bot running, which gives html-access to IRC > even when the corporate firewalls are not liking that ;-) > > regards > Alexander > -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
RE: Bookmarking, History and JSF
> -Original Message- > From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] > Sent: Friday, January 27, 2006 12:09 PM > To: MyFaces Development > Subject: Re: Bookmarking, History and JSF > > > We could discuss it with Ed Burns this evening in the ##jsf chat. > > Lately he's online almost every day... > > I am not using irc, but maybe I'll install a client. but today (at > evening I am traveling) > But you could bring out this topic, right ? > > -Matthias Just got to make sure i understand the issue completely. It seems that manolito has connected a few times lately as well... BTW: I have a deputy bot running, which gives html-access to IRC even when the corporate firewalls are not liking that ;-) regards Alexander
Re: Bookmarking, History and JSF
Yes, sounds good. I'm not online this evening, either, but if Jesse can hook-up with Ed on this topic, that would be great. regards, Martin On 1/27/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > We could discuss it with Ed Burns this evening in the ##jsf chat. > > Lately he's online almost every day... > > I am not using irc, but maybe I'll install a client. but today (at > evening I am traveling) > But you could bring out this topic, right ? > > -Matthias > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
We could optionally do that - don't know if that is practical. I've discussed with Manfred some more, and he suggests to do the following: give t:saveState an optional "bookmarkable"=true attribute, and with that decide on some of the state to be saved even though the tree-state is lost. we could also log an error to the user when the maximum url-size is exceeded. regards, Martin On 1/27/06, Werner Punz <[EMAIL PROTECTED]> wrote: > Matthias Wessendorf schrieb: > > > > > Why not rendering a link to a NonFacesRequestServlet ? > > (like the tobago stuff) > > > Servlet = bad idea needs an additional entry in the web.xml > (and just check how many problems the tomahawk extension filter > already causes) > The obvious place probably would be the extension filter (which has to > be there anyway) > or a phase listener - which would be even better because that one > would not need any entry at all from the users side if packed correctly. > > > > For links like > > foo.faces?param1=foo¶m2=bar > > > > your backing bean construktor (or init() of ViewController) needs to > > perform some lookups. > > That could be easily done by that mentioned servlet, without doing > > that parameter catching stuff inside of your backing bean. > > > > @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs > > plan for enabling bookmarkable URLs ? > > > > -Matthias > > > >> regards, > >> > >> Martin > >> > >> -- > >> > >> http://www.irian.at > >> > >> Your JSF powerhouse - > >> JSF Consulting, Development and > >> Courses in English and German > >> > >> Professional Support for Apache MyFaces > >> > > > > > > -- > > Matthias Wessendorf > > Zülpicher Wall 12, 239 > > 50674 Köln > > http://www.wessendorf.net > > mwessendorf-at-gmail-dot-com > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
> We could discuss it with Ed Burns this evening in the ##jsf chat. > Lately he's online almost every day... I am not using irc, but maybe I'll install a client. but today (at evening I am traveling) But you could bring out this topic, right ? -Matthias
Re: Bookmarking, History and JSF
> Servlet = bad idea needs an additional entry in the web.xml > (and just check how many problems the tomahawk extension filter > already causes) > The obvious place probably would be the extension filter (which has to > be there anyway) > or a phase listener - which would be even better because that one > would not need any entry at all from the users side if packed correctly. yeah! right. so, instead of servlet let's take a PhaseListener. But we definitly need (or should provide) a facility to populate your backing beans, instead of doing parameter catching inside of that bean. that was my message :-) -Matthias
Re: Bookmarking, History and JSF
Matthias Wessendorf schrieb: > > Why not rendering a link to a NonFacesRequestServlet ? > (like the tobago stuff) > Servlet = bad idea needs an additional entry in the web.xml (and just check how many problems the tomahawk extension filter already causes) The obvious place probably would be the extension filter (which has to be there anyway) or a phase listener - which would be even better because that one would not need any entry at all from the users side if packed correctly. > For links like > foo.faces?param1=foo¶m2=bar > > your backing bean construktor (or init() of ViewController) needs to > perform some lookups. > That could be easily done by that mentioned servlet, without doing > that parameter catching stuff inside of your backing bean. > > @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs > plan for enabling bookmarkable URLs ? > > -Matthias > >> regards, >> >> Martin >> >> -- >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> > > > -- > Matthias Wessendorf > Zülpicher Wall 12, 239 > 50674 Köln > http://www.wessendorf.net > mwessendorf-at-gmail-dot-com >
RE: Bookmarking, History and JSF
> > @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs > plan for enabling bookmarkable URLs ? We could discuss it with Ed Burns this evening in the ##jsf chat. Lately he's online almost every day... regards Alexander
Re: Bookmarking, History and JSF
Here goes the link for that servlet http://tinyurl.com/8dv43 inside of invokeApplication() you could do some stuff w/ ValueBindings to populate your bean. -Matthias On 1/27/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi > > > Now, what do I want to be able to see in my history or to bookmark? I > > want to bookmark simple pages, where state is not so important at all. > > Or only a small portion of the state is important... > > > Those simple pages I usually refer to with an "action" attribute that > > is put (as a string) directly on the or > > tag, right? > > right, since no *complicated* calculation for action outcome is needed. > > > Why not render out this action attribute as a parameter to the URL of > > the link optionally, not submitting a form and loosing all JSF state, > > but having a bookmarkable link? > > a feature like this makes it more easier to implement systems like ebay, > where bookmarkable URLs are a must! > > > > > The developer can decide then: > > - do I need this link to be bookmarked > > - do I want this link to use the plain old JSF posting system with > > state-saving. > > ok > > > > > Enhancement: we could additionally render out params to this link as - > > yes, right, params to the URL. So people can optionally build there > > web-apps just like they were used to when JSF wasn't around. > > so something like > > host/app/foo.faces?param1=foo¶m2=bar > > > > > Good idea - bad idea - better idea ;) ? > > Why not rendering a link to a NonFacesRequestServlet ? > (like the tobago stuff) > > For links like > foo.faces?param1=foo¶m2=bar > > your backing bean construktor (or init() of ViewController) needs to > perform some lookups. > That could be easily done by that mentioned servlet, without doing > that parameter catching stuff inside of your backing bean. > > @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs > plan for enabling bookmarkable URLs ? > > -Matthias > > > regards, > > > > Martin > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > > > -- > Matthias Wessendorf > Zülpicher Wall 12, 239 > 50674 Köln > http://www.wessendorf.net > mwessendorf-at-gmail-dot-com > -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
Re: Bookmarking, History and JSF
Hi > Now, what do I want to be able to see in my history or to bookmark? I > want to bookmark simple pages, where state is not so important at all. > Or only a small portion of the state is important... > Those simple pages I usually refer to with an "action" attribute that > is put (as a string) directly on the or > tag, right? right, since no *complicated* calculation for action outcome is needed. > Why not render out this action attribute as a parameter to the URL of > the link optionally, not submitting a form and loosing all JSF state, > but having a bookmarkable link? a feature like this makes it more easier to implement systems like ebay, where bookmarkable URLs are a must! > > The developer can decide then: > - do I need this link to be bookmarked > - do I want this link to use the plain old JSF posting system with > state-saving. ok > > Enhancement: we could additionally render out params to this link as - > yes, right, params to the URL. So people can optionally build there > web-apps just like they were used to when JSF wasn't around. so something like host/app/foo.faces?param1=foo¶m2=bar > > Good idea - bad idea - better idea ;) ? Why not rendering a link to a NonFacesRequestServlet ? (like the tobago stuff) For links like foo.faces?param1=foo¶m2=bar your backing bean construktor (or init() of ViewController) needs to perform some lookups. That could be easily done by that mentioned servlet, without doing that parameter catching stuff inside of your backing bean. @Manfred: I guess I saw a ticket in RI stuff for this. What's the EGs plan for enabling bookmarkable URLs ? -Matthias > regards, > > Martin > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
Re: Bookmarking, History and JSF
Yes, this is the plan. regards, Martin On 1/27/06, Cash, Jamie <[EMAIL PROTECTED]> wrote: > Hopefully this will then render as a complete URL, which will allow search > engines to follow the links as well! > > We currently have to create outputLinks on the page, bypassing the action > system, in order to give the search engine robots a path to follow. > > Excellent idea! > > > > -Original Message- > From: Mario Ivankovits [mailto:[EMAIL PROTECTED] > Sent: 27 January 2006 09:58 > To: MyFaces Development > Subject: Re: Bookmarking, History and JSF > > > Hi! > > JSF - minus complete state-saving + GET-processing + binding into the > > Navigation-framework of JSF > And then ALLOW_JAVASCRIPT=false will start working again too? > > Ciao, > Mario > > > > INTERNATIONAL FINANCIAL DATA SERVICES (UK) LTD Tel: +44 1268 44 3000 > ** N O T I C E * > > This message and any attachments is intended only for the individual or > company to which it is addressed and may contain > information which is privileged, confidential or prohibited from disclosure > or unauthorised use. If the recipient of this > transmission is not the intended recipient, or the employee or agent > responsible for delivering such materials to the > intended recipient, you are hereby notified that any use, any form of > reproduction, dissemination, copying, disclosure, > modification, distribution and/or publication of this e-mail message or its > attachments other than by it's intended > recipient is strictly prohibited by the sender. If you have received it in > error, please notify us immediately by > telephone on the number above and destroy the message and all copies in your > possession. > > International Financial Data Services (UK) Ltd is authorised and regulated by > the Financial Services Authority. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > > ** > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Bookmarking, History and JSF
Let's take one step at a time ;) regards, Martin On 1/27/06, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > let's hope it will... THAT WOULD BE HYPER-GREAT ;-) > > -Original Message- > From: Mario Ivankovits [mailto:[EMAIL PROTECTED] > Sent: Friday, January 27, 2006 10:58 AM > To: MyFaces Development > Subject: Re: Bookmarking, History and JSF > > Hi! > > JSF - minus complete state-saving + GET-processing + binding into the > > Navigation-framework of JSF > And then ALLOW_JAVASCRIPT=false will start working again too? > > Ciao, > Mario > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Bookmarking, History and JSF
Hopefully this will then render as a complete URL, which will allow search engines to follow the links as well! We currently have to create outputLinks on the page, bypassing the action system, in order to give the search engine robots a path to follow. Excellent idea! -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: 27 January 2006 09:58 To: MyFaces Development Subject: Re: Bookmarking, History and JSF Hi! > JSF - minus complete state-saving + GET-processing + binding into the > Navigation-framework of JSF And then ALLOW_JAVASCRIPT=false will start working again too? Ciao, Mario INTERNATIONAL FINANCIAL DATA SERVICES (UK) LTD Tel: +44 1268 44 3000 ** N O T I C E * This message and any attachments is intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential or prohibited from disclosure or unauthorised use. If the recipient of this transmission is not the intended recipient, or the employee or agent responsible for delivering such materials to the intended recipient, you are hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication of this e-mail message or its attachments other than by it's intended recipient is strictly prohibited by the sender. If you have received it in error, please notify us immediately by telephone on the number above and destroy the message and all copies in your possession. International Financial Data Services (UK) Ltd is authorised and regulated by the Financial Services Authority. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. **
RE: Bookmarking, History and JSF
let's hope it will... THAT WOULD BE HYPER-GREAT ;-) -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Friday, January 27, 2006 10:58 AM To: MyFaces Development Subject: Re: Bookmarking, History and JSF Hi! > JSF - minus complete state-saving + GET-processing + binding into the > Navigation-framework of JSF And then ALLOW_JAVASCRIPT=false will start working again too? Ciao, Mario
Re: Bookmarking, History and JSF
Hi! > JSF - minus complete state-saving + GET-processing + binding into the > Navigation-framework of JSF And then ALLOW_JAVASCRIPT=false will start working again too? Ciao, Mario
Re: Bookmarking, History and JSF
+1000 for a get Martin Marinschek schrieb: > Hi all, > > I'm having ideas again. Must come from too much work with JSF ;) > > My idea: > > Bookmarking is a problem with JSF, right? Except you use h:outputLink, > but then there's this slight problem with not being in the action > system anymore ;) > > Now, what do I want to be able to see in my history or to bookmark? I > want to bookmark simple pages, where state is not so important at all. > Or only a small portion of the state is important... > > Those simple pages I usually refer to with an "action" attribute that > is put (as a string) directly on the or > tag, right? > > Why not render out this action attribute as a parameter to the URL of > the link optionally, not submitting a form and loosing all JSF state, > but having a bookmarkable link? > > The developer can decide then: > - do I need this link to be bookmarked > - do I want this link to use the plain old JSF posting system with > state-saving. > > Enhancement: we could additionally render out params to this link as - > yes, right, params to the URL. So people can optionally build there > web-apps just like they were used to when JSF wasn't around. > > Good idea - bad idea - better idea ;) ? > > regards, > > Martin > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
Re: Bookmarking, History and JSF
Yes, exactly. JSF - minus complete state-saving + GET-processing + binding into the Navigation-framework of JSF=we don't get people running around calling us names anymore ;) regards, Martin On 1/27/06, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > to put it in a nutshell: > > add GET-processing to JSF... > > +100 ;-) > > regards > Alexander > > -Original Message- > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > Sent: Friday, January 27, 2006 10:35 AM > To: MyFaces Development > Subject: Bookmarking, History and JSF > > Hi all, > > I'm having ideas again. Must come from too much work with JSF ;) > > My idea: > > Bookmarking is a problem with JSF, right? Except you use h:outputLink, > but then there's this slight problem with not being in the action > system anymore ;) > > Now, what do I want to be able to see in my history or to bookmark? I > want to bookmark simple pages, where state is not so important at all. > Or only a small portion of the state is important... > > Those simple pages I usually refer to with an "action" attribute that > is put (as a string) directly on the or > tag, right? > > Why not render out this action attribute as a parameter to the URL of > the link optionally, not submitting a form and loosing all JSF state, > but having a bookmarkable link? > > The developer can decide then: > - do I need this link to be bookmarked > - do I want this link to use the plain old JSF posting system with > state-saving. > > Enhancement: we could additionally render out params to this link as - > yes, right, params to the URL. So people can optionally build there > web-apps just like they were used to when JSF wasn't around. > > Good idea - bad idea - better idea ;) ? > > regards, > > Martin > > -- > > 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
RE: Bookmarking, History and JSF
to put it in a nutshell: add GET-processing to JSF... +100 ;-) regards Alexander -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Friday, January 27, 2006 10:35 AM To: MyFaces Development Subject: Bookmarking, History and JSF Hi all, I'm having ideas again. Must come from too much work with JSF ;) My idea: Bookmarking is a problem with JSF, right? Except you use h:outputLink, but then there's this slight problem with not being in the action system anymore ;) Now, what do I want to be able to see in my history or to bookmark? I want to bookmark simple pages, where state is not so important at all. Or only a small portion of the state is important... Those simple pages I usually refer to with an "action" attribute that is put (as a string) directly on the or tag, right? Why not render out this action attribute as a parameter to the URL of the link optionally, not submitting a form and loosing all JSF state, but having a bookmarkable link? The developer can decide then: - do I need this link to be bookmarked - do I want this link to use the plain old JSF posting system with state-saving. Enhancement: we could additionally render out params to this link as - yes, right, params to the URL. So people can optionally build there web-apps just like they were used to when JSF wasn't around. Good idea - bad idea - better idea ;) ? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Bookmarking, History and JSF
Hi all, I'm having ideas again. Must come from too much work with JSF ;) My idea: Bookmarking is a problem with JSF, right? Except you use h:outputLink, but then there's this slight problem with not being in the action system anymore ;) Now, what do I want to be able to see in my history or to bookmark? I want to bookmark simple pages, where state is not so important at all. Or only a small portion of the state is important... Those simple pages I usually refer to with an "action" attribute that is put (as a string) directly on the or tag, right? Why not render out this action attribute as a parameter to the URL of the link optionally, not submitting a form and loosing all JSF state, but having a bookmarkable link? The developer can decide then: - do I need this link to be bookmarked - do I want this link to use the plain old JSF posting system with state-saving. Enhancement: we could additionally render out params to this link as - yes, right, params to the URL. So people can optionally build there web-apps just like they were used to when JSF wasn't around. Good idea - bad idea - better idea ;) ? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
