@Mark With your 'exclude-area' idea you are referring to something like Orchestra's <o:separateConversationContext>, right? I think this could be a really interesting feature for some usecases and we should definitively support it.
Regarding the auto detection for links that have to be decorated: I'm not really sure if there is a need to explicitly configure a set of domains for this. I guess the decorating is somehow similar to what HttpServletResponse.encodeURL() does and would even be implemented by wrapping it (or the corresponding stuff in ExternalContext), correct? So why don't we simply decorate all links that go though encodeURL unless we are in an exclude area case? Christian 2013/4/23 Jason Porter <lightguard...@gmail.com> > 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 > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
