Interesting idea. What does the rest of the community think?
On Tue, Apr 23, 2013 at 11:01 AM, Mark Struberg <strub...@yahoo.de> wrote: > yes, we will certainly need to do lots of testing with this new approach. > But it seems much more in sync with the JSF-2.2 idea which requires to > detect the proper windowId even before the restore-view phase. In the old > CODI implementation we parsed it from a custom Component which we added to > the view tree ourselfs. maybe we can do both. > > There was also an idea about having an 'exclude-area'. Means a tag which > will exclude the containing GET links from using the browser tab detection. > We might also think about a mechanism to detect the links which need to > get decorated. Something like > > <ds:windowId domain="this, someurl.com, otherurl.org"/> > For other links we will not add the windowId nor store away the dom tree > for our 'snapshot view' on the intermediate page. > > LieGrue, > strub > > > > > ----- Original Message ----- > > From: Jason Porter <lightguard...@gmail.com> > > To: "deltaspike-dev@incubator.apache.org" < > deltaspike-dev@incubator.apache.org> > > Cc: > > Sent: Tuesday, 23 April 2013, 18:22 > > Subject: Re: windowId postback detection > > > > I'm good either way, but the custom component idea seems to be consensus, > > also if the user doesn't want it they can always leave out the new > > component. > > > > > > On Mon, Apr 22, 2013 at 12:38 AM, Thomas Andraschko < > > andraschko.tho...@gmail.com> wrote: > > > >> +1 for the custom component > >> > >> > >> 2013/4/22 Christian Kaltepoth <christ...@kaltepoth.de> > >> > >> > I like the idea of a custom component because it makes it more > > explicit > >> > what the component is used for and perhaps would even provide more > >> control > >> > over what is happening. > >> > > >> > So +1 for a custom component > >> > > >> > > >> > 2013/4/21 Mark Struberg <strub...@yahoo.de> > >> > > >> > > Gerhard brought up another alternative: simply provide a > > component > >> which > >> > > doesn't render any html but adds the windowhandler.js and > > stores the > >> > > component in the ViewRoot. > >> > > > >> > > LieGrue, > >> > > strub > >> > > > >> > > > >> > > > >> > > > >> > > ----- Original Message ----- > >> > > > From: Romain Manni-Bucau <rmannibu...@gmail.com> > >> > > > To: Mark Struberg <strub...@yahoo.de>; > >> > > deltaspike-dev@incubator.apache.org > >> > > > Cc: > >> > > > Sent: Sunday, 21 April 2013, 20:56 > >> > > > Subject: Re: windowId postback detection > >> > > > > >> > > > 1 sounds easier to track too > >> > > > Le 21 avr. 2013 18:09, "Mark Struberg" > > <strub...@yahoo.de> a > >> > > > écrit : > >> > > > > >> > > >> Hi! > >> > > >> > >> > > >> There are technically 2 options for extracting the > > windowId on > >> POSTs: > >> > > >> > >> > > >> 1.) setting a hidden UIOutput component in the ViewRoot > >> > > >> > >> > > >> > >> > > >> 2.) provide a custom renderkit/ResponseStateManager > >> > > >> > >> > > >> I think 1.) is much easier. Any input? > >> > > >> > >> > > >> LIeGrue, > >> > > >> strub > >> > > >> > >> > > >> > >> > > > > >> > > > >> > > >> > > >> > > >> > -- > >> > Christian Kaltepoth > >> > Blog: http://blog.kaltepoth.de/ > >> > Twitter: http://twitter.com/chkal > >> > GitHub: https://github.com/chkal > >> > > >> > > > > > > > > -- > > Jason Porter > > http://en.gravatar.com/lightguardjp > > > -- Jason Porter http://en.gravatar.com/lightguardjp
