Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: error (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=k8fijiLUR60fyzU9IEiq0rJbpSvr1NePNESCxlGclfA1Huk/5UUo8pGneZWuIWHcI/1/OjLLfdzaFWMYbx84fwgT1Dc7fmHuAHTrwO1e6cFZw6xHJXbKgmQR33MaUwJrhJex+4R8xjyc++6FrZQdt+aCZrz4z9YQl+R0IWI/OWc=;
References: <1366560521.23403.YahooMailNeo@web28904.mail.ir2.yahoo.com>
	<CACLE=7MSrzvpTS+WQH+AL5KK7nRjS_TWiheH0TY60EycBQPCeg@mail.gmail.com>
	<1366574544.17445.YahooMailNeo@web28903.mail.ir2.yahoo.com>
	<CAEXeC6y5b6+HArzkVQKVjHeQ_EHyf9GeXL7Pb-o=i+ShAwVeTw@mail.gmail.com>
	<CAAuOd=UpcbjYrHiUCkLcDDV9A2RVwRbZ6+s1bMVa8HX_FZNC3Q@mail.gmail.com>
	<CAF9TksOcsWSg9i0fJB6BJwaZ04SbOuQ=Of0wxG6HG-v6FQ1Urw@mail.gmail.com>
	<1366736472.62966.YahooMailNeo@web28903.mail.ir2.yahoo.com>
	<CAF9TksPVntGeLEGY=NxE21Qwg021zXVW_dH7qAw+n_V25ty6dw@mail.gmail.com>
 <CAEXeC6zNc0GJUKFb-nMt6Sb+8L3L_tnUHzMSrdBm6MBMA=CVPg@mail.gmail.com>
Message-ID: <1366790086.45031.YahooMailNeo@web28906.mail.ir2.yahoo.com>
Date: Wed, 24 Apr 2013 08:54:46 +0100 (BST)
From: Mark Struberg <struberg@yahoo.de>
Reply-To: Mark Struberg <struberg@yahoo.de>
Subject: Re: windowId postback detection
To: "deltaspike-dev@incubator.apache.org"
 <deltaspike-dev@incubator.apache.org>
In-Reply-To: 
 <CAEXeC6zNc0GJUKFb-nMt6Sb+8L3L_tnUHzMSrdBm6MBMA=CVPg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

It's not exactly the same but goes in the same direction.=0A=0ACurrently we=
 have 4 'operation modes' for each request (see ClientWindowConfig. =0A=0A*=
 NONE: no @WindowScoped will be available for this request=0A=0A* LAZY: the=
 windowId will be verified and ensured on the client side via a JavaScript =
comparison of the windowId and window.name and if it doesn't fit then we fo=
rce a page refresh with the correct windowId: CON: the first page hit will =
still have the old windowId and might touch beans from this other window.=
=0A=0A* CLIENTWINDOW: each GET request first gets an intermediate page (win=
dowhandler.html) which checks if the windowName and windowId fit. If not ->=
 new windowId will get requested. If they fit, we reload the page with the =
verified windowId. This 2nd request finally hits the xhtml page. The interm=
ediate windowhandler page takes around 1ms to get served and is blazingly f=
ast on the client. To prevent flickering if the target page takes some time=
 to render we kind of take a DOM screenshot from the original page and disp=
lay it on the intermediate page.=0A=0A* CUSTOM: A user might implement his =
own ClientWindow. Not sure though how we will integrate this. Currently doe=
sn't work :)=0A=0AThe user can choose them via his own ClientWindowConfig (=
or @Specializes DefaultClientWindowConfig) for each request. E.g. a Request=
 from an internal address in a company (in our case the university) gets th=
e ClientWndow (intermediate html page which ensures the windowId is correct=
) and external addresses get rendered directly. Bots and other crawlers sho=
uld also get the direct page for example.=0A=0ANow for the 'exclude region'=
 sometimes you don't like to decorate target links with the windowId, nor d=
o you like to store the DOM tree in the localstorage. E.g. if you show cust=
omer generated context which is not secured or if you have links to externa=
l pages.=0AThis is more or less a security mechanism.=0A=0ALieGrue,=0Astrub=
=0A=0A=0A=0A=0A=0A>________________________________=0A> From: Christian Kal=
tepoth <christian@kaltepoth.de>=0A>To: deltaspike-dev@incubator.apache.org =
=0A>Cc: Mark Struberg <struberg@yahoo.de> =0A>Sent: Tuesday, 23 April 2013,=
 23:15=0A>Subject: Re: windowId postback detection=0A> =0A>=0A>@Mark=0A>Wit=
h your 'exclude-area' idea you are referring to something like=0A>Orchestra=
's <o:separateConversationContext>, right? I think this could be a=0A>reall=
y interesting feature for some usecases and we=0A>should definitively suppo=
rt it.=0A>=0A>Regarding the auto detection for links that have to be decora=
ted: I'm not=0A>really sure if there is a need to explicitly configure a se=
t of domains for=0A>this. I guess the decorating is somehow similar to what=
=0A>HttpServletResponse.encodeURL() does and would even be implemented by=
=0A>wrapping it (or the corresponding stuff in ExternalContext), correct? S=
o=0A>why don't we simply decorate all links that go though encodeURL unless=
 we=0A>are in an exclude area case?=0A>=0A>Christian=0A>=0A>=0A>=0A>=0A>201=
3/4/23 Jason Porter <lightguard.jp@gmail.com>=0A>=0A>> Interesting idea. Wh=
at does the rest of the community think?=0A>>=0A>>=0A>> On Tue, Apr 23, 201=
3 at 11:01 AM, Mark Struberg <struberg@yahoo.de> wrote:=0A>>=0A>> > yes, we=
 will certainly need to do lots of testing with this new approach.=0A>> > B=
ut it seems much more in sync with the JSF-2.2 idea which requires to=0A>> =
> detect the proper windowId even before the restore-view phase. In the old=
=0A>> > CODI implementation we parsed it from a custom Component which we a=
dded=0A>> to=0A>> > the view tree ourselfs. maybe we can do both.=0A>> >=0A=
>> > There was also an idea about having an 'exclude-area'. Means a tag whi=
ch=0A>> > will exclude the containing GET links from using the browser tab=
=0A>> detection.=0A>> > We might also think about a mechanism to detect the=
 links which need to=0A>> > get decorated. Something like=0A>> >=0A>> > <ds=
:windowId domain=3D"this, someurl.com, otherurl.org"/>=0A>> > For other lin=
ks we will not add the windowId nor store away the dom tree=0A>> > for our =
'snapshot view' on the intermediate page.=0A>> >=0A>> > LieGrue,=0A>> > str=
ub=0A>> >=0A>> >=0A>> >=0A>> >=0A>> > ----- Original Message -----=0A>> > >=
 From: Jason Porter <lightguard.jp@gmail.com>=0A>> > > To: "deltaspike-dev@=
incubator.apache.org" <=0A>> > deltaspike-dev@incubator.apache.org>=0A>> > =
> Cc:=0A>> > > Sent: Tuesday, 23 April 2013, 18:22=0A>> > > Subject: Re: wi=
ndowId postback detection=0A>> > >=0A>> > > I'm good either way, but the cu=
stom component idea seems to be=0A>> consensus,=0A>> > > also if the user d=
oesn't want it they can always leave out the new=0A>> > > component.=0A>> >=
 >=0A>> > >=0A>> > > On Mon, Apr 22, 2013 at 12:38 AM, Thomas Andraschko <=
=0A>> > > andraschko.thomas@gmail.com> wrote:=0A>> > >=0A>> > >>=A0 +1 for =
the custom component=0A>> > >>=0A>> > >>=0A>> > >>=A0 2013/4/22 Christian K=
altepoth <christian@kaltepoth.de>=0A>> > >>=0A>> > >>=A0 > I like the idea =
of a custom component because it makes it more=0A>> > > explicit=0A>> > >>=
=A0 > what the component is used for and perhaps would even provide more=0A=
>> > >>=A0 control=0A>> > >>=A0 > over what is happening.=0A>> > >>=A0 >=0A=
>> > >>=A0 > So +1 for a custom component=0A>> > >>=A0 >=0A>> > >>=A0 >=0A>=
> > >>=A0 > 2013/4/21 Mark Struberg <struberg@yahoo.de>=0A>> > >>=A0 >=0A>>=
 > >>=A0 > > Gerhard brought up another alternative: simply provide a=0A>> =
> > component=0A>> > >>=A0 which=0A>> > >>=A0 > > doesn't render any html b=
ut adds the windowhandler.js and=0A>> > > stores the=0A>> > >>=A0 > > compo=
nent in the ViewRoot.=0A>> > >>=A0 > >=0A>> > >>=A0 > > LieGrue,=0A>> > >>=
=A0 > > strub=0A>> > >>=A0 > >=0A>> > >>=A0 > >=0A>> > >>=A0 > >=0A>> > >>=
=A0 > >=0A>> > >>=A0 > > ----- Original Message -----=0A>> > >>=A0 > > > Fr=
om: Romain Manni-Bucau <rmannibucau@gmail.com>=0A>> > >>=A0 > > > To: Mark =
Struberg <struberg@yahoo.de>;=0A>> > >>=A0 > > deltaspike-dev@incubator.apa=
che.org=0A>> > >>=A0 > > > Cc:=0A>> > >>=A0 > > > Sent: Sunday, 21 April 20=
13, 20:56=0A>> > >>=A0 > > > Subject: Re: windowId postback detection=0A>> =
> >>=A0 > > >=0A>> > >>=A0 > > > 1 sounds easier to track too=0A>> > >>=A0 =
> > > Le 21 avr. 2013 18:09, "Mark Struberg"=0A>> > > <struberg@yahoo.de> a=
=0A>> > >>=A0 > > > =E9crit :=0A>> > >>=A0 > > >=0A>> > >>=A0 > > >>=A0 Hi!=
=0A>> > >>=A0 > > >>=0A>> > >>=A0 > > >>=A0 There are technically 2 options=
 for extracting the=0A>> > > windowId on=0A>> > >>=A0 POSTs:=0A>> > >>=A0 >=
 > >>=0A>> > >>=A0 > > >>=A0 1.) setting a hidden UIOutput component in the=
 ViewRoot=0A>> > >>=A0 > > >>=0A>> > >>=A0 > > >>=0A>> > >>=A0 > > >>=A0 2.=
) provide a custom renderkit/ResponseStateManager=0A>> > >>=A0 > > >>=0A>> =
> >>=A0 > > >>=A0 I think 1.) is much easier. Any input?=0A>> > >>=A0 > > >=
>=0A>> > >>=A0 > > >>=A0 LIeGrue,=0A>> > >>=A0 > > >>=A0 strub=0A>> > >>=A0=
 > > >>=0A>> > >>=A0 > > >>=0A>> > >>=A0 > > >=0A>> > >>=A0 > >=0A>> > >>=
=A0 >=0A>> > >>=A0 >=0A>> > >>=A0 >=0A>> > >>=A0 > --=0A>> > >>=A0 > Christ=
ian Kaltepoth=0A>> > >>=A0 > Blog: http://blog.kaltepoth.de/=0A>> > >>=A0 >=
 Twitter: http://twitter.com/chkal=0A>> > >>=A0 > GitHub: https://github.co=
m/chkal=0A>> > >>=A0 >=0A>> > >>=0A>> > >=0A>> > >=0A>> > >=0A>> > > --=0A>=
> > > Jason Porter=0A>> > > http://en.gravatar.com/lightguardjp=0A>> > >=0A=
>> >=0A>>=0A>>=0A>>=0A>> --=0A>> Jason Porter=0A>> http://en.gravatar.com/l=
ightguardjp=0A>>=0A>=0A>=0A>=0A>-- =0A>Christian Kaltepoth=0A>Blog: http://=
blog.kaltepoth.de/=0A>Twitter: http://twitter.com/chkal=0A>GitHub: https://=
github.com/chkal=0A>=0A>