You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@gmail.com> on 2011/11/17 19:15:05 UTC
[core extcdi] is required to create another proposal about windowId?
Hi
In the last days there was some work in these issues:
(EXTCDI-242) improve ClientSideWindowHandler windowId passing via cookie
(EXTCDI-241) Allow users of the ClientSideWindowHandler to specify if
it should get applied per Request
(EXTCDI-240) Enhance ClientSideWindowHandler - remove flickering, etc
Just one question: if the flickering problem was fixed on the current
solution done on EXTCDI, it is still necessary to create an
implementation inside myfaces core for windowId? This problem is on my
list of things to do, so it is better to ask first.
regards,
Leonardo Uribe
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I have created this issue:
https://issues.apache.org/jira/browse/MYFACES-3404
and attached a patch. I think the code proposed is enough simple. If
no objections I'll commit that code soon.
Good to know that HTML5 can be used to fix flash scope. Thinking about
it maybe is possible to create a flash scope using windowId concept
only. After all, flash scope discard values stored on previous
requests automatically, so by definition it should not support back
button, right?. I know the current strategy uses a requestId key, so
change the code could require some changes. We could make something
inside myfaces to check if windowId is present and if so, use it for
flash scope, otherwise use the old strategy with cookies.
regards,
Leonardo Uribe
2011/11/20 Jakob Korherr <ja...@gmail.com>:
> Sounds reasonable.
>
> At least it is possible with HTML5 to do the following:
>
> 1) URL: index.xhtml?requestId=xyz
> 2) HTML5: change to index.xhtml without reloading (see [1])
>
> Regards,
> Jakob
>
> [1] http://spoiledmilk.dk/blog/html5-changing-the-browser-url-without-refreshing-page
>
> 2011/11/20 Mark Struberg <st...@yahoo.de>:
>> woah, just had a crazy idea!
>>
>> The root of all evil with the FlashScoped is that fact that we use cookies for transporting the requestToken, right?
>>
>> With HTML5 browsers we could also just add the reqeustToken to the GET request and use the html5 history API to cleanup the URL later.
>> Should work, right? Jakob, you have done some work in this area, does this sound reasonable?
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Leonardo Uribe <lu...@gmail.com>
>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg <st...@yahoo.de>
>>> Cc:
>>> Sent: Saturday, November 19, 2011 12:05 AM
>>> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>>>
>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>>> 1. To implement 2. it is necessary
>>>>> a "requestId". MyFaces FlashImpl uses a counter and store its
>>> value inside
>>>>> a cookie
>>>>
>>>> The trick could be the same which I do atm for the 2nd windowId request:
>>> Each URL always contains the windowId, and the cookie name also contains the
>>> windowId. This way 2 tabs cannot get the same cookie...
>>>>
>>>
>>> Yes, the idea could be to generate a request id together with the
>>> windowId (in fact the proposal in the wiki mentions generate a
>>> windowId and a requestId). Since the spec already provide an interface
>>> to implement Flash scope (javax.faces.context.Flash abstract class),
>>> there is no need to create another interface to fill the gap between
>>> requestId management and Flash object, instead create an alternate
>>> Flash scope object, reusing the original code and fixing the parts
>>> related to cookie management with the alternate code. Note Flash scope
>>> "changes" before render response phase, so you need to do some
>>> handling between the current and the next requestId.
>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Leonardo Uribe <lu...@gmail.com>
>>>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg
>>> <st...@yahoo.de>
>>>>> Cc:
>>>>> Sent: Friday, November 18, 2011 11:08 PM
>>>>> Subject: Re: [core extcdi] is required to create another proposal about
>>> windowId?
>>>>>
>>>>> Hi
>>>>>
>>>>> MS>> The ClientSideWindowHandler solution in CODI looks good so
>>> far, but
>>>>> there
>>>>> MS>> is still a lot to do.
>>>>>
>>>>> MS>> And like every technology, it has it's pros and cons...
>>>>>
>>>>> MS>> What do you think about making the windowId provider
>>> pluggable in
>>>>> MyFaces
>>>>> MS>> core first?
>>>>>
>>>>> I have been thinking about every possible option we have for implement
>>> this and
>>>>> the conclusion was the best way is make something like the hack done in
>>> CODI or
>>>>> a "variant" of it, like the one described on:
>>>>>
>>>>> http://wiki.apache.org/myfaces/Drafts/WindowId
>>>>>
>>>>> (Mixed approach of the first prototype)
>>>>>
>>>>> From the point of view of MyFaces Core, any solution should be bound to
>>> the
>>>>> renderkit in some way. So, windowId concept has sense to include it on
>>> the spec
>>>>> but its implementation should be done according to the renderkit. If
>>> the
>>>>> renderkit handles html, do the hack proposed but if is xml, do other
>>> thing
>>>>> and so on. It sounds like something to do outside MyFaces Core.
>>> Basically the
>>>>> problem is how to create an interface about something that could
>>> require
>>>>> changes over the renderkit/viewhandler?.
>>>>>
>>>>> Maybe we can minimize the problem, and provide an interface like this:
>>>>>
>>>>> public interface WindowIdRenderKitAware
>>>>> {
>>>>> public String getCurrentWindowId(FacesContext facesContext);
>>>>> }
>>>>>
>>>>> But let the details about how to "plug" all pieces inside
>>> CODI.
>>>>> MyFaces Core
>>>>> just offer the "integration point", and the default algorithm
>>> just do
>>>>> what is
>>>>> doing right now. Who should implement this interface? the renderkit,
>>> even if
>>>>> in the implementation the value can be stored inside FacesContext
>>> attribute
>>>>> map or request map. There exists a RenderKitWrapper interface, so it is
>>>>> easy to create a wrapper for default HTML_BASIC renderkit or any other
>>> and
>>>>> then scan through the wrappers and the first one implementing the
>>> interface
>>>>> will be the choosen.
>>>>>
>>>>> MS>> The REAL problem with JSF and multiple tabs is that once you
>>> open 2
>>>>> tabs
>>>>> MS>> and click in 1 of them often enough, then you will destroy
>>> the state
>>>>> of
>>>>> MS>> the view in the other tab as well somewhen. Usually after 20
>>> requests
>>>>> MS>> (default).
>>>>>
>>>>> There are two points where this logic could be useful inside MyFaces
>>> Core :
>>>>>
>>>>> 1. Server side state
>>>>> 2. Flash scope
>>>>>
>>>>> But in practice the only really relevant is 1. To implement 2. it is
>>> necessary
>>>>> a "requestId". MyFaces FlashImpl uses a counter and store its
>>> value
>>>>> inside
>>>>> a cookie. To fix this scope properly, the best is create a
>>> ExternalContext
>>>>> wrapper and provide and alternate Flash object, but that sounds like
>>> something
>>>>> that can be done outside MyFaces Core. If you are using CDI scopes, it
>>> sounds
>>>>> reasonable to provide an alternate Flash scope in CODI.
>>>>>
>>>>> If we can just modify the logic inside server side state to include
>>>>> "windowId"
>>>>> concept, it will be enough.
>>>>>
>>>>> MS>> To come over this, we need to store the n last views not
>>> only per
>>>>> session,
>>>>> MS>> but also per browser tab (==windowId).
>>>>> MS>> Of course, there can be lots of fancy stuff done to detect
>>> closed
>>>>> tabs,
>>>>> MS>> etc. But all this is much more stable if we really have the
>>>>> opportunity
>>>>> MS>> to distinguish between tabs. We can e.g. also introduce a
>>>>> configuration
>>>>> MS>> for maximum allowed tabs, to reduce memory blasting.
>>>>>
>>>>> Really since all state is stored in session, if the session is
>>> invalidated all
>>>>> tabs are removed from memory. Basically we already have params for max
>>> number
>>>>> of sessions and max number of logical sessions (which in fact can be
>>> seen
>>>>> as "tabs"). So what we have right now is ok, we just need to
>>> include
>>>>> windowId
>>>>> concept into the logic and that's it.
>>>>>
>>>>> MS>> All this is actually completely independent of how the
>>> windowId
>>>>> get's
>>>>> MS>> created and checked imo.
>>>>>
>>>>> Yes, that's right.
>>>>>
>>>>> MS>> I now tend to do the following (just atm creating a better
>>> playground
>>>>> MS>> example in CODI + hack on the ClientSideWindowHandler):
>>>>> MS>>
>>>>> MS>> a.) the cookie thingy is pretty bääh. it just doesn't
>>> work if a
>>>>> user clicks
>>>>> MS>> quickly through a list and opens lots of 'detail
>>> pages' on
>>>>> different tabs
>>>>> MS>> within 2 seconds.
>>>>> MS>>
>>>>> MS>> b.) it's currently a 'one or the other' thingy,
>>> and I now
>>>>> thought about
>>>>> MS>> combining the lazyWindowIdDropp.js and the current
>>> windowhandler.js
>>>>> MS>>
>>>>> MS>> My current research goes into the direction of
>>>>> MS>>
>>>>> MS>> 1.) always adding the windowId to each and every link and
>>> transport
>>>>> the
>>>>> MS>> windowId only via this parameter.
>>>>> MS>>
>>>>> MS>> 2.) For HTML5-browsers (detected via UserAgent) I render the
>>>>> MS>> windowhandler.html intermediate page which does all the
>>> fancy stuff
>>>>> of
>>>>> MS>> dynamically applying the old DOM on the intermediate page,
>>> etc. For
>>>>> other
>>>>> MS>> clients we rely on the lazyWindowId script.
>>>>>
>>>>> Ok, sounds promising. So, I'll focus on how to fix the logic for
>>> myfaces
>>>>> core server side state saving
>>>>> (org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the
>>> alternative
>>>>> proposed in this mail (WindowIdRenderKitAware interface, and then use a
>>>>> RenderKit wrapper).
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>>>> I now tend to do the following (just atm creating a better
>>> playground
>>>>> example in CODI + hack on the ClientSideWindowHandler):
>>>>>>
>>>>>> a.) the cookie thingy is pretty bääh. it just doesn't work if
>>> a user
>>>>> clicks quickly through a list and opens lots of 'detail pages'
>>> on
>>>>> different tabs within 2 seconds.
>>>>>>
>>>>>> b.) it's currently a 'one or the other' thingy, and I
>>> now
>>>>> thought about combining the lazyWindowIdDropp.js and the current
>>>>> windowhandler.js
>>>>>>
>>>>>> My current research goes into the direction of
>>>>>>
>>>>>> 1.) always adding the windowId to each and every link and
>>> transport the
>>>>> windowId only via this parameter.
>>>>>>
>>>>>> 2.) For HTML5-browsers (detected via UserAgent) I render the
>>>>> windowhandler.html intermediate page which does all the fancy stuff of
>>>>> dynamically applying the old DOM on the intermediate page, etc. For
>>> other
>>>>> clients we rely on the lazyWindowId script.
>>>>>>
>>>>>> Any help is welcome.
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: Jakob Korherr <ja...@gmail.com>
>>>>>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark
>>> Struberg
>>>>> <st...@yahoo.de>
>>>>>>> Cc:
>>>>>>> Sent: Friday, November 18, 2011 2:23 PM
>>>>>>> Subject: Re: [core extcdi] is required to create another
>>> proposal about
>>>>> windowId?
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>> PS: btw, a PhD student in my institute made me aware of a
>>> trick
>>>>> with the
>>>>>>> browser history. I think Jakob also already researched in this
>>>>> direction:
>>>>>>>>
>>>>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>>>>>> This mechanism does only 1 GET request (mine does 2), but
>>> with
>>>>> pure AJAX
>>>>>>> you imo cannot fully replace the header once the window is
>>> fully
>>>>> loaded. Thus
>>>>>>> you cannot easily handle dynamically loaded CSS, background
>>> images, etc
>>>>> with
>>>>>>> this approach.
>>>>>>>
>>>>>>> Yeap, I did some research in this area and also came across
>>>>>>> https://github.com/balupton/history.js (there are actually a
>>> hand full
>>>>>>> of projects on github which accomplish the same thing). This
>>> sure is a
>>>>>>> very good way of implementing a rich web 2.0 application with
>>> working
>>>>>>> history (--> back button), facebook and twitter are surely
>>> the most
>>>>>>> famous examples of this technique.
>>>>>>>
>>>>>>> However, Mark is right: doing this, you will end up in a lot
>>> of
>>>>>>> browser related problems when it comes to dynamic loading of
>>>>>>> stylesheets, scripts, etc.. Facebook and twitter managed to
>>> get this
>>>>>>> working for their purposes, but IMO it is not that easy for a
>>> standard
>>>>>>> JSF developer/architect.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jakob
>>>>>>>
>>>>>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> The ClientSideWindowHandler solution in CODI looks good
>>> so far,
>>>>> but there
>>>>>>> is still a lot to do.
>>>>>>>>
>>>>>>>> And like every technology, it has it's pros and
>>> cons...
>>>>>>>>
>>>>>>>> What do you think about making the windowId provider
>>> pluggable in
>>>>> MyFaces
>>>>>>> core first?
>>>>>>>>
>>>>>>>> The REAL problem with JSF and multiple tabs is that once
>>> you open
>>>>> 2 tabs
>>>>>>> and click in 1 of them often enough, then you will destroy the
>>> state of
>>>>> the view
>>>>>>> in the other tab as well somewhen. Usually after 20 requests
>>> (default).
>>>>>>>>
>>>>>>>> To come over this, we need to store the n last views not
>>> only per
>>>>> session,
>>>>>>> but also per browser tab (==windowId).
>>>>>>>> Of course, there can be lots of fancy stuff done to
>>> detect closed
>>>>> tabs,
>>>>>>> etc. But all this is much more stable if we really have the
>>> opportunity
>>>>> to
>>>>>>> distinguish between tabs. We can e.g. also introduce a
>>> configuration
>>>>> for maximum
>>>>>>> allowed tabs, to reduce memory blasting.
>>>>>>>>
>>>>>>>> All this is actually completely independent of how the
>>> windowId
>>>>> get's
>>>>>>> created and checked imo.
>>>>>>>>
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>>>>>>>
>>>>>>>> PS: btw, a PhD student in my institute made me aware of a
>>> trick
>>>>> with the
>>>>>>> browser history. I think Jakob also already researched in this
>>>>> direction:
>>>>>>>>
>>>>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>>>>>> This mechanism does only 1 GET request (mine does 2), but
>>> with
>>>>> pure AJAX
>>>>>>> you imo cannot fully replace the header once the window is
>>> fully
>>>>> loaded. Thus
>>>>>>> you cannot easily handle dynamically loaded CSS, background
>>> images, etc
>>>>> with
>>>>>>> this approach.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: Leonardo Uribe <lu...@gmail.com>
>>>>>>>>> To: MyFaces Development
>>> <de...@myfaces.apache.org>
>>>>>>>>> Cc:
>>>>>>>>> Sent: Thursday, November 17, 2011 9:39 PM
>>>>>>>>> Subject: Re: [core extcdi] is required to create
>>> another
>>>>> proposal about
>>>>>>> windowId?
>>>>>>>>>
>>>>>>>>> Hi Gerhard
>>>>>>>>>
>>>>>>>>> Ok, good to know that. I'll work on a solution
>>> based on
>>>>> the
>>>>>>> previous
>>>>>>>>> discussions about it to have more options in this
>>> case.
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>>
>>>>>>>>> Leonardo Uribe
>>>>>>>>>
>>>>>>>>> 2011/11/17 Gerhard Petracek
>>>>> <ge...@gmail.com>:
>>>>>>>>>> hi leo,
>>>>>>>>>>
>>>>>>>>>> as soon as the new approach works, we can
>>> suggest it for
>>>>> jsf 2.2.
>>>>>>>>>> however, since it's only compatible with
>>> html5, we
>>>>> have to
>>>>>>> suggest a
>>>>>>>>>> 2nd approach (e.g. the default behaviour of
>>> codi).
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>> gerhard
>>>>>>>>>>
>>>>>>>>>> http://www.irian.at
>>>>>>>>>>
>>>>>>>>>> Your JSF powerhouse -
>>>>>>>>>> JSF Consulting, Development and
>>>>>>>>>> Courses in English and German
>>>>>>>>>>
>>>>>>>>>> Professional Support for Apache MyFaces
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2011/11/17 Werner Punz
>>> <we...@gmail.com>:
>>>>>>>>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi
>>>>>>>>>>>>
>>>>>>>>>>>> In the last days there was some work in
>>> these
>>>>> issues:
>>>>>>>>>>>>
>>>>>>>>>>>> (EXTCDI-242) improve
>>> ClientSideWindowHandler
>>>>> windowId
>>>>>>> passing via
>>>>>>>>> cookie
>>>>>>>>>>>> (EXTCDI-241) Allow users of the
>>>>> ClientSideWindowHandler to
>>>>>>> specify
>>>>>>>>> if
>>>>>>>>>>>> it should get applied per Request
>>>>>>>>>>>> (EXTCDI-240) Enhance
>>> ClientSideWindowHandler -
>>>>> remove
>>>>>>> flickering,
>>>>>>>>> etc
>>>>>>>>>>>>
>>>>>>>>>>>> Just one question: if the flickering
>>> problem was
>>>>> fixed on
>>>>>>> the
>>>>>>>>> current
>>>>>>>>>>>> solution done on EXTCDI, it is still
>>> necessary to
>>>>> create
>>>>>>> an
>>>>>>>>>>>> implementation inside myfaces core for
>>> windowId?
>>>>> This
>>>>>>> problem is on
>>>>>>>>> my
>>>>>>>>>>>> list of things to do, so it is better to
>>> ask
>>>>> first.
>>>>>>>>>>>>
>>>>>>>>>>>> regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Leonardo Uribe
>>>>>>>>>>>>
>>>>>>>>>>> Good question, I guess we need something for
>>> WindowID
>>>>> handling
>>>>>>> for
>>>>>>>>> jsf2.2
>>>>>>>>>>> especially given in hindisght of what is
>>> planned for
>>>>> 2.2
>>>>>>> according to
>>>>>>>>> Ed
>>>>>>>>>>> Burns blog but the final answer for now is
>>> up to the
>>>>> CODI
>>>>>>> guys.
>>>>>>>>>>>
>>>>>>>>>>> Werner
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jakob Korherr
>>>>>>>
>>>>>>> blog: http://www.jakobk.com
>>>>>>> twitter: http://twitter.com/jakobkorherr
>>>>>>> work: http://www.irian.at
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Jakob Korherr <ja...@gmail.com>.
Sounds reasonable.
At least it is possible with HTML5 to do the following:
1) URL: index.xhtml?requestId=xyz
2) HTML5: change to index.xhtml without reloading (see [1])
Regards,
Jakob
[1] http://spoiledmilk.dk/blog/html5-changing-the-browser-url-without-refreshing-page
2011/11/20 Mark Struberg <st...@yahoo.de>:
> woah, just had a crazy idea!
>
> The root of all evil with the FlashScoped is that fact that we use cookies for transporting the requestToken, right?
>
> With HTML5 browsers we could also just add the reqeustToken to the GET request and use the html5 history API to cleanup the URL later.
> Should work, right? Jakob, you have done some work in this area, does this sound reasonable?
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Leonardo Uribe <lu...@gmail.com>
>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg <st...@yahoo.de>
>> Cc:
>> Sent: Saturday, November 19, 2011 12:05 AM
>> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>>
>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>> 1. To implement 2. it is necessary
>>>> a "requestId". MyFaces FlashImpl uses a counter and store its
>> value inside
>>>> a cookie
>>>
>>> The trick could be the same which I do atm for the 2nd windowId request:
>> Each URL always contains the windowId, and the cookie name also contains the
>> windowId. This way 2 tabs cannot get the same cookie...
>>>
>>
>> Yes, the idea could be to generate a request id together with the
>> windowId (in fact the proposal in the wiki mentions generate a
>> windowId and a requestId). Since the spec already provide an interface
>> to implement Flash scope (javax.faces.context.Flash abstract class),
>> there is no need to create another interface to fill the gap between
>> requestId management and Flash object, instead create an alternate
>> Flash scope object, reusing the original code and fixing the parts
>> related to cookie management with the alternate code. Note Flash scope
>> "changes" before render response phase, so you need to do some
>> handling between the current and the next requestId.
>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> ----- Original Message -----
>>>> From: Leonardo Uribe <lu...@gmail.com>
>>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg
>> <st...@yahoo.de>
>>>> Cc:
>>>> Sent: Friday, November 18, 2011 11:08 PM
>>>> Subject: Re: [core extcdi] is required to create another proposal about
>> windowId?
>>>>
>>>> Hi
>>>>
>>>> MS>> The ClientSideWindowHandler solution in CODI looks good so
>> far, but
>>>> there
>>>> MS>> is still a lot to do.
>>>>
>>>> MS>> And like every technology, it has it's pros and cons...
>>>>
>>>> MS>> What do you think about making the windowId provider
>> pluggable in
>>>> MyFaces
>>>> MS>> core first?
>>>>
>>>> I have been thinking about every possible option we have for implement
>> this and
>>>> the conclusion was the best way is make something like the hack done in
>> CODI or
>>>> a "variant" of it, like the one described on:
>>>>
>>>> http://wiki.apache.org/myfaces/Drafts/WindowId
>>>>
>>>> (Mixed approach of the first prototype)
>>>>
>>>> From the point of view of MyFaces Core, any solution should be bound to
>> the
>>>> renderkit in some way. So, windowId concept has sense to include it on
>> the spec
>>>> but its implementation should be done according to the renderkit. If
>> the
>>>> renderkit handles html, do the hack proposed but if is xml, do other
>> thing
>>>> and so on. It sounds like something to do outside MyFaces Core.
>> Basically the
>>>> problem is how to create an interface about something that could
>> require
>>>> changes over the renderkit/viewhandler?.
>>>>
>>>> Maybe we can minimize the problem, and provide an interface like this:
>>>>
>>>> public interface WindowIdRenderKitAware
>>>> {
>>>> public String getCurrentWindowId(FacesContext facesContext);
>>>> }
>>>>
>>>> But let the details about how to "plug" all pieces inside
>> CODI.
>>>> MyFaces Core
>>>> just offer the "integration point", and the default algorithm
>> just do
>>>> what is
>>>> doing right now. Who should implement this interface? the renderkit,
>> even if
>>>> in the implementation the value can be stored inside FacesContext
>> attribute
>>>> map or request map. There exists a RenderKitWrapper interface, so it is
>>>> easy to create a wrapper for default HTML_BASIC renderkit or any other
>> and
>>>> then scan through the wrappers and the first one implementing the
>> interface
>>>> will be the choosen.
>>>>
>>>> MS>> The REAL problem with JSF and multiple tabs is that once you
>> open 2
>>>> tabs
>>>> MS>> and click in 1 of them often enough, then you will destroy
>> the state
>>>> of
>>>> MS>> the view in the other tab as well somewhen. Usually after 20
>> requests
>>>> MS>> (default).
>>>>
>>>> There are two points where this logic could be useful inside MyFaces
>> Core :
>>>>
>>>> 1. Server side state
>>>> 2. Flash scope
>>>>
>>>> But in practice the only really relevant is 1. To implement 2. it is
>> necessary
>>>> a "requestId". MyFaces FlashImpl uses a counter and store its
>> value
>>>> inside
>>>> a cookie. To fix this scope properly, the best is create a
>> ExternalContext
>>>> wrapper and provide and alternate Flash object, but that sounds like
>> something
>>>> that can be done outside MyFaces Core. If you are using CDI scopes, it
>> sounds
>>>> reasonable to provide an alternate Flash scope in CODI.
>>>>
>>>> If we can just modify the logic inside server side state to include
>>>> "windowId"
>>>> concept, it will be enough.
>>>>
>>>> MS>> To come over this, we need to store the n last views not
>> only per
>>>> session,
>>>> MS>> but also per browser tab (==windowId).
>>>> MS>> Of course, there can be lots of fancy stuff done to detect
>> closed
>>>> tabs,
>>>> MS>> etc. But all this is much more stable if we really have the
>>>> opportunity
>>>> MS>> to distinguish between tabs. We can e.g. also introduce a
>>>> configuration
>>>> MS>> for maximum allowed tabs, to reduce memory blasting.
>>>>
>>>> Really since all state is stored in session, if the session is
>> invalidated all
>>>> tabs are removed from memory. Basically we already have params for max
>> number
>>>> of sessions and max number of logical sessions (which in fact can be
>> seen
>>>> as "tabs"). So what we have right now is ok, we just need to
>> include
>>>> windowId
>>>> concept into the logic and that's it.
>>>>
>>>> MS>> All this is actually completely independent of how the
>> windowId
>>>> get's
>>>> MS>> created and checked imo.
>>>>
>>>> Yes, that's right.
>>>>
>>>> MS>> I now tend to do the following (just atm creating a better
>> playground
>>>> MS>> example in CODI + hack on the ClientSideWindowHandler):
>>>> MS>>
>>>> MS>> a.) the cookie thingy is pretty bääh. it just doesn't
>> work if a
>>>> user clicks
>>>> MS>> quickly through a list and opens lots of 'detail
>> pages' on
>>>> different tabs
>>>> MS>> within 2 seconds.
>>>> MS>>
>>>> MS>> b.) it's currently a 'one or the other' thingy,
>> and I now
>>>> thought about
>>>> MS>> combining the lazyWindowIdDropp.js and the current
>> windowhandler.js
>>>> MS>>
>>>> MS>> My current research goes into the direction of
>>>> MS>>
>>>> MS>> 1.) always adding the windowId to each and every link and
>> transport
>>>> the
>>>> MS>> windowId only via this parameter.
>>>> MS>>
>>>> MS>> 2.) For HTML5-browsers (detected via UserAgent) I render the
>>>> MS>> windowhandler.html intermediate page which does all the
>> fancy stuff
>>>> of
>>>> MS>> dynamically applying the old DOM on the intermediate page,
>> etc. For
>>>> other
>>>> MS>> clients we rely on the lazyWindowId script.
>>>>
>>>> Ok, sounds promising. So, I'll focus on how to fix the logic for
>> myfaces
>>>> core server side state saving
>>>> (org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the
>> alternative
>>>> proposed in this mail (WindowIdRenderKitAware interface, and then use a
>>>> RenderKit wrapper).
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>>> I now tend to do the following (just atm creating a better
>> playground
>>>> example in CODI + hack on the ClientSideWindowHandler):
>>>>>
>>>>> a.) the cookie thingy is pretty bääh. it just doesn't work if
>> a user
>>>> clicks quickly through a list and opens lots of 'detail pages'
>> on
>>>> different tabs within 2 seconds.
>>>>>
>>>>> b.) it's currently a 'one or the other' thingy, and I
>> now
>>>> thought about combining the lazyWindowIdDropp.js and the current
>>>> windowhandler.js
>>>>>
>>>>> My current research goes into the direction of
>>>>>
>>>>> 1.) always adding the windowId to each and every link and
>> transport the
>>>> windowId only via this parameter.
>>>>>
>>>>> 2.) For HTML5-browsers (detected via UserAgent) I render the
>>>> windowhandler.html intermediate page which does all the fancy stuff of
>>>> dynamically applying the old DOM on the intermediate page, etc. For
>> other
>>>> clients we rely on the lazyWindowId script.
>>>>>
>>>>> Any help is welcome.
>>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Jakob Korherr <ja...@gmail.com>
>>>>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark
>> Struberg
>>>> <st...@yahoo.de>
>>>>>> Cc:
>>>>>> Sent: Friday, November 18, 2011 2:23 PM
>>>>>> Subject: Re: [core extcdi] is required to create another
>> proposal about
>>>> windowId?
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> PS: btw, a PhD student in my institute made me aware of a
>> trick
>>>> with the
>>>>>> browser history. I think Jakob also already researched in this
>>>> direction:
>>>>>>>
>>>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>>>>> This mechanism does only 1 GET request (mine does 2), but
>> with
>>>> pure AJAX
>>>>>> you imo cannot fully replace the header once the window is
>> fully
>>>> loaded. Thus
>>>>>> you cannot easily handle dynamically loaded CSS, background
>> images, etc
>>>> with
>>>>>> this approach.
>>>>>>
>>>>>> Yeap, I did some research in this area and also came across
>>>>>> https://github.com/balupton/history.js (there are actually a
>> hand full
>>>>>> of projects on github which accomplish the same thing). This
>> sure is a
>>>>>> very good way of implementing a rich web 2.0 application with
>> working
>>>>>> history (--> back button), facebook and twitter are surely
>> the most
>>>>>> famous examples of this technique.
>>>>>>
>>>>>> However, Mark is right: doing this, you will end up in a lot
>> of
>>>>>> browser related problems when it comes to dynamic loading of
>>>>>> stylesheets, scripts, etc.. Facebook and twitter managed to
>> get this
>>>>>> working for their purposes, but IMO it is not that easy for a
>> standard
>>>>>> JSF developer/architect.
>>>>>>
>>>>>> Regards,
>>>>>> Jakob
>>>>>>
>>>>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>>>>> Hi!
>>>>>>>
>>>>>>> The ClientSideWindowHandler solution in CODI looks good
>> so far,
>>>> but there
>>>>>> is still a lot to do.
>>>>>>>
>>>>>>> And like every technology, it has it's pros and
>> cons...
>>>>>>>
>>>>>>> What do you think about making the windowId provider
>> pluggable in
>>>> MyFaces
>>>>>> core first?
>>>>>>>
>>>>>>> The REAL problem with JSF and multiple tabs is that once
>> you open
>>>> 2 tabs
>>>>>> and click in 1 of them often enough, then you will destroy the
>> state of
>>>> the view
>>>>>> in the other tab as well somewhen. Usually after 20 requests
>> (default).
>>>>>>>
>>>>>>> To come over this, we need to store the n last views not
>> only per
>>>> session,
>>>>>> but also per browser tab (==windowId).
>>>>>>> Of course, there can be lots of fancy stuff done to
>> detect closed
>>>> tabs,
>>>>>> etc. But all this is much more stable if we really have the
>> opportunity
>>>> to
>>>>>> distinguish between tabs. We can e.g. also introduce a
>> configuration
>>>> for maximum
>>>>>> allowed tabs, to reduce memory blasting.
>>>>>>>
>>>>>>> All this is actually completely independent of how the
>> windowId
>>>> get's
>>>>>> created and checked imo.
>>>>>>>
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>> PS: btw, a PhD student in my institute made me aware of a
>> trick
>>>> with the
>>>>>> browser history. I think Jakob also already researched in this
>>>> direction:
>>>>>>>
>>>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>>>>> This mechanism does only 1 GET request (mine does 2), but
>> with
>>>> pure AJAX
>>>>>> you imo cannot fully replace the header once the window is
>> fully
>>>> loaded. Thus
>>>>>> you cannot easily handle dynamically loaded CSS, background
>> images, etc
>>>> with
>>>>>> this approach.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: Leonardo Uribe <lu...@gmail.com>
>>>>>>>> To: MyFaces Development
>> <de...@myfaces.apache.org>
>>>>>>>> Cc:
>>>>>>>> Sent: Thursday, November 17, 2011 9:39 PM
>>>>>>>> Subject: Re: [core extcdi] is required to create
>> another
>>>> proposal about
>>>>>> windowId?
>>>>>>>>
>>>>>>>> Hi Gerhard
>>>>>>>>
>>>>>>>> Ok, good to know that. I'll work on a solution
>> based on
>>>> the
>>>>>> previous
>>>>>>>> discussions about it to have more options in this
>> case.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Leonardo Uribe
>>>>>>>>
>>>>>>>> 2011/11/17 Gerhard Petracek
>>>> <ge...@gmail.com>:
>>>>>>>>> hi leo,
>>>>>>>>>
>>>>>>>>> as soon as the new approach works, we can
>> suggest it for
>>>> jsf 2.2.
>>>>>>>>> however, since it's only compatible with
>> html5, we
>>>> have to
>>>>>> suggest a
>>>>>>>>> 2nd approach (e.g. the default behaviour of
>> codi).
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>> gerhard
>>>>>>>>>
>>>>>>>>> http://www.irian.at
>>>>>>>>>
>>>>>>>>> Your JSF powerhouse -
>>>>>>>>> JSF Consulting, Development and
>>>>>>>>> Courses in English and German
>>>>>>>>>
>>>>>>>>> Professional Support for Apache MyFaces
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2011/11/17 Werner Punz
>> <we...@gmail.com>:
>>>>>>>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>>
>>>>>>>>>>> In the last days there was some work in
>> these
>>>> issues:
>>>>>>>>>>>
>>>>>>>>>>> (EXTCDI-242) improve
>> ClientSideWindowHandler
>>>> windowId
>>>>>> passing via
>>>>>>>> cookie
>>>>>>>>>>> (EXTCDI-241) Allow users of the
>>>> ClientSideWindowHandler to
>>>>>> specify
>>>>>>>> if
>>>>>>>>>>> it should get applied per Request
>>>>>>>>>>> (EXTCDI-240) Enhance
>> ClientSideWindowHandler -
>>>> remove
>>>>>> flickering,
>>>>>>>> etc
>>>>>>>>>>>
>>>>>>>>>>> Just one question: if the flickering
>> problem was
>>>> fixed on
>>>>>> the
>>>>>>>> current
>>>>>>>>>>> solution done on EXTCDI, it is still
>> necessary to
>>>> create
>>>>>> an
>>>>>>>>>>> implementation inside myfaces core for
>> windowId?
>>>> This
>>>>>> problem is on
>>>>>>>> my
>>>>>>>>>>> list of things to do, so it is better to
>> ask
>>>> first.
>>>>>>>>>>>
>>>>>>>>>>> regards,
>>>>>>>>>>>
>>>>>>>>>>> Leonardo Uribe
>>>>>>>>>>>
>>>>>>>>>> Good question, I guess we need something for
>> WindowID
>>>> handling
>>>>>> for
>>>>>>>> jsf2.2
>>>>>>>>>> especially given in hindisght of what is
>> planned for
>>>> 2.2
>>>>>> according to
>>>>>>>> Ed
>>>>>>>>>> Burns blog but the final answer for now is
>> up to the
>>>> CODI
>>>>>> guys.
>>>>>>>>>>
>>>>>>>>>> Werner
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jakob Korherr
>>>>>>
>>>>>> blog: http://www.jakobk.com
>>>>>> twitter: http://twitter.com/jakobkorherr
>>>>>> work: http://www.irian.at
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Mark Struberg <st...@yahoo.de>.
woah, just had a crazy idea!
The root of all evil with the FlashScoped is that fact that we use cookies for transporting the requestToken, right?
With HTML5 browsers we could also just add the reqeustToken to the GET request and use the html5 history API to cleanup the URL later.
Should work, right? Jakob, you have done some work in this area, does this sound reasonable?
LieGrue,
strub
----- Original Message -----
> From: Leonardo Uribe <lu...@gmail.com>
> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Saturday, November 19, 2011 12:05 AM
> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>
> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>> 1. To implement 2. it is necessary
>>> a "requestId". MyFaces FlashImpl uses a counter and store its
> value inside
>>> a cookie
>>
>> The trick could be the same which I do atm for the 2nd windowId request:
> Each URL always contains the windowId, and the cookie name also contains the
> windowId. This way 2 tabs cannot get the same cookie...
>>
>
> Yes, the idea could be to generate a request id together with the
> windowId (in fact the proposal in the wiki mentions generate a
> windowId and a requestId). Since the spec already provide an interface
> to implement Flash scope (javax.faces.context.Flash abstract class),
> there is no need to create another interface to fill the gap between
> requestId management and Flash object, instead create an alternate
> Flash scope object, reusing the original code and fixing the parts
> related to cookie management with the alternate code. Note Flash scope
> "changes" before render response phase, so you need to do some
> handling between the current and the next requestId.
>
>> LieGrue,
>> strub
>>
>>
>> ----- Original Message -----
>>> From: Leonardo Uribe <lu...@gmail.com>
>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg
> <st...@yahoo.de>
>>> Cc:
>>> Sent: Friday, November 18, 2011 11:08 PM
>>> Subject: Re: [core extcdi] is required to create another proposal about
> windowId?
>>>
>>> Hi
>>>
>>> MS>> The ClientSideWindowHandler solution in CODI looks good so
> far, but
>>> there
>>> MS>> is still a lot to do.
>>>
>>> MS>> And like every technology, it has it's pros and cons...
>>>
>>> MS>> What do you think about making the windowId provider
> pluggable in
>>> MyFaces
>>> MS>> core first?
>>>
>>> I have been thinking about every possible option we have for implement
> this and
>>> the conclusion was the best way is make something like the hack done in
> CODI or
>>> a "variant" of it, like the one described on:
>>>
>>> http://wiki.apache.org/myfaces/Drafts/WindowId
>>>
>>> (Mixed approach of the first prototype)
>>>
>>> From the point of view of MyFaces Core, any solution should be bound to
> the
>>> renderkit in some way. So, windowId concept has sense to include it on
> the spec
>>> but its implementation should be done according to the renderkit. If
> the
>>> renderkit handles html, do the hack proposed but if is xml, do other
> thing
>>> and so on. It sounds like something to do outside MyFaces Core.
> Basically the
>>> problem is how to create an interface about something that could
> require
>>> changes over the renderkit/viewhandler?.
>>>
>>> Maybe we can minimize the problem, and provide an interface like this:
>>>
>>> public interface WindowIdRenderKitAware
>>> {
>>> public String getCurrentWindowId(FacesContext facesContext);
>>> }
>>>
>>> But let the details about how to "plug" all pieces inside
> CODI.
>>> MyFaces Core
>>> just offer the "integration point", and the default algorithm
> just do
>>> what is
>>> doing right now. Who should implement this interface? the renderkit,
> even if
>>> in the implementation the value can be stored inside FacesContext
> attribute
>>> map or request map. There exists a RenderKitWrapper interface, so it is
>>> easy to create a wrapper for default HTML_BASIC renderkit or any other
> and
>>> then scan through the wrappers and the first one implementing the
> interface
>>> will be the choosen.
>>>
>>> MS>> The REAL problem with JSF and multiple tabs is that once you
> open 2
>>> tabs
>>> MS>> and click in 1 of them often enough, then you will destroy
> the state
>>> of
>>> MS>> the view in the other tab as well somewhen. Usually after 20
> requests
>>> MS>> (default).
>>>
>>> There are two points where this logic could be useful inside MyFaces
> Core :
>>>
>>> 1. Server side state
>>> 2. Flash scope
>>>
>>> But in practice the only really relevant is 1. To implement 2. it is
> necessary
>>> a "requestId". MyFaces FlashImpl uses a counter and store its
> value
>>> inside
>>> a cookie. To fix this scope properly, the best is create a
> ExternalContext
>>> wrapper and provide and alternate Flash object, but that sounds like
> something
>>> that can be done outside MyFaces Core. If you are using CDI scopes, it
> sounds
>>> reasonable to provide an alternate Flash scope in CODI.
>>>
>>> If we can just modify the logic inside server side state to include
>>> "windowId"
>>> concept, it will be enough.
>>>
>>> MS>> To come over this, we need to store the n last views not
> only per
>>> session,
>>> MS>> but also per browser tab (==windowId).
>>> MS>> Of course, there can be lots of fancy stuff done to detect
> closed
>>> tabs,
>>> MS>> etc. But all this is much more stable if we really have the
>>> opportunity
>>> MS>> to distinguish between tabs. We can e.g. also introduce a
>>> configuration
>>> MS>> for maximum allowed tabs, to reduce memory blasting.
>>>
>>> Really since all state is stored in session, if the session is
> invalidated all
>>> tabs are removed from memory. Basically we already have params for max
> number
>>> of sessions and max number of logical sessions (which in fact can be
> seen
>>> as "tabs"). So what we have right now is ok, we just need to
> include
>>> windowId
>>> concept into the logic and that's it.
>>>
>>> MS>> All this is actually completely independent of how the
> windowId
>>> get's
>>> MS>> created and checked imo.
>>>
>>> Yes, that's right.
>>>
>>> MS>> I now tend to do the following (just atm creating a better
> playground
>>> MS>> example in CODI + hack on the ClientSideWindowHandler):
>>> MS>>
>>> MS>> a.) the cookie thingy is pretty bääh. it just doesn't
> work if a
>>> user clicks
>>> MS>> quickly through a list and opens lots of 'detail
> pages' on
>>> different tabs
>>> MS>> within 2 seconds.
>>> MS>>
>>> MS>> b.) it's currently a 'one or the other' thingy,
> and I now
>>> thought about
>>> MS>> combining the lazyWindowIdDropp.js and the current
> windowhandler.js
>>> MS>>
>>> MS>> My current research goes into the direction of
>>> MS>>
>>> MS>> 1.) always adding the windowId to each and every link and
> transport
>>> the
>>> MS>> windowId only via this parameter.
>>> MS>>
>>> MS>> 2.) For HTML5-browsers (detected via UserAgent) I render the
>>> MS>> windowhandler.html intermediate page which does all the
> fancy stuff
>>> of
>>> MS>> dynamically applying the old DOM on the intermediate page,
> etc. For
>>> other
>>> MS>> clients we rely on the lazyWindowId script.
>>>
>>> Ok, sounds promising. So, I'll focus on how to fix the logic for
> myfaces
>>> core server side state saving
>>> (org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the
> alternative
>>> proposed in this mail (WindowIdRenderKitAware interface, and then use a
>>> RenderKit wrapper).
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>> I now tend to do the following (just atm creating a better
> playground
>>> example in CODI + hack on the ClientSideWindowHandler):
>>>>
>>>> a.) the cookie thingy is pretty bääh. it just doesn't work if
> a user
>>> clicks quickly through a list and opens lots of 'detail pages'
> on
>>> different tabs within 2 seconds.
>>>>
>>>> b.) it's currently a 'one or the other' thingy, and I
> now
>>> thought about combining the lazyWindowIdDropp.js and the current
>>> windowhandler.js
>>>>
>>>> My current research goes into the direction of
>>>>
>>>> 1.) always adding the windowId to each and every link and
> transport the
>>> windowId only via this parameter.
>>>>
>>>> 2.) For HTML5-browsers (detected via UserAgent) I render the
>>> windowhandler.html intermediate page which does all the fancy stuff of
>>> dynamically applying the old DOM on the intermediate page, etc. For
> other
>>> clients we rely on the lazyWindowId script.
>>>>
>>>> Any help is welcome.
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Jakob Korherr <ja...@gmail.com>
>>>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark
> Struberg
>>> <st...@yahoo.de>
>>>>> Cc:
>>>>> Sent: Friday, November 18, 2011 2:23 PM
>>>>> Subject: Re: [core extcdi] is required to create another
> proposal about
>>> windowId?
>>>>>
>>>>> Hi,
>>>>>
>>>>>> PS: btw, a PhD student in my institute made me aware of a
> trick
>>> with the
>>>>> browser history. I think Jakob also already researched in this
>>> direction:
>>>>>>
>>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>>>> This mechanism does only 1 GET request (mine does 2), but
> with
>>> pure AJAX
>>>>> you imo cannot fully replace the header once the window is
> fully
>>> loaded. Thus
>>>>> you cannot easily handle dynamically loaded CSS, background
> images, etc
>>> with
>>>>> this approach.
>>>>>
>>>>> Yeap, I did some research in this area and also came across
>>>>> https://github.com/balupton/history.js (there are actually a
> hand full
>>>>> of projects on github which accomplish the same thing). This
> sure is a
>>>>> very good way of implementing a rich web 2.0 application with
> working
>>>>> history (--> back button), facebook and twitter are surely
> the most
>>>>> famous examples of this technique.
>>>>>
>>>>> However, Mark is right: doing this, you will end up in a lot
> of
>>>>> browser related problems when it comes to dynamic loading of
>>>>> stylesheets, scripts, etc.. Facebook and twitter managed to
> get this
>>>>> working for their purposes, but IMO it is not that easy for a
> standard
>>>>> JSF developer/architect.
>>>>>
>>>>> Regards,
>>>>> Jakob
>>>>>
>>>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>>>> Hi!
>>>>>>
>>>>>> The ClientSideWindowHandler solution in CODI looks good
> so far,
>>> but there
>>>>> is still a lot to do.
>>>>>>
>>>>>> And like every technology, it has it's pros and
> cons...
>>>>>>
>>>>>> What do you think about making the windowId provider
> pluggable in
>>> MyFaces
>>>>> core first?
>>>>>>
>>>>>> The REAL problem with JSF and multiple tabs is that once
> you open
>>> 2 tabs
>>>>> and click in 1 of them often enough, then you will destroy the
> state of
>>> the view
>>>>> in the other tab as well somewhen. Usually after 20 requests
> (default).
>>>>>>
>>>>>> To come over this, we need to store the n last views not
> only per
>>> session,
>>>>> but also per browser tab (==windowId).
>>>>>> Of course, there can be lots of fancy stuff done to
> detect closed
>>> tabs,
>>>>> etc. But all this is much more stable if we really have the
> opportunity
>>> to
>>>>> distinguish between tabs. We can e.g. also introduce a
> configuration
>>> for maximum
>>>>> allowed tabs, to reduce memory blasting.
>>>>>>
>>>>>> All this is actually completely independent of how the
> windowId
>>> get's
>>>>> created and checked imo.
>>>>>>
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>> PS: btw, a PhD student in my institute made me aware of a
> trick
>>> with the
>>>>> browser history. I think Jakob also already researched in this
>>> direction:
>>>>>>
>>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>>>> This mechanism does only 1 GET request (mine does 2), but
> with
>>> pure AJAX
>>>>> you imo cannot fully replace the header once the window is
> fully
>>> loaded. Thus
>>>>> you cannot easily handle dynamically loaded CSS, background
> images, etc
>>> with
>>>>> this approach.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: Leonardo Uribe <lu...@gmail.com>
>>>>>>> To: MyFaces Development
> <de...@myfaces.apache.org>
>>>>>>> Cc:
>>>>>>> Sent: Thursday, November 17, 2011 9:39 PM
>>>>>>> Subject: Re: [core extcdi] is required to create
> another
>>> proposal about
>>>>> windowId?
>>>>>>>
>>>>>>> Hi Gerhard
>>>>>>>
>>>>>>> Ok, good to know that. I'll work on a solution
> based on
>>> the
>>>>> previous
>>>>>>> discussions about it to have more options in this
> case.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Leonardo Uribe
>>>>>>>
>>>>>>> 2011/11/17 Gerhard Petracek
>>> <ge...@gmail.com>:
>>>>>>>> hi leo,
>>>>>>>>
>>>>>>>> as soon as the new approach works, we can
> suggest it for
>>> jsf 2.2.
>>>>>>>> however, since it's only compatible with
> html5, we
>>> have to
>>>>> suggest a
>>>>>>>> 2nd approach (e.g. the default behaviour of
> codi).
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>> http://www.irian.at
>>>>>>>>
>>>>>>>> Your JSF powerhouse -
>>>>>>>> JSF Consulting, Development and
>>>>>>>> Courses in English and German
>>>>>>>>
>>>>>>>> Professional Support for Apache MyFaces
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2011/11/17 Werner Punz
> <we...@gmail.com>:
>>>>>>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>>>>>>>
>>>>>>>>>> Hi
>>>>>>>>>>
>>>>>>>>>> In the last days there was some work in
> these
>>> issues:
>>>>>>>>>>
>>>>>>>>>> (EXTCDI-242) improve
> ClientSideWindowHandler
>>> windowId
>>>>> passing via
>>>>>>> cookie
>>>>>>>>>> (EXTCDI-241) Allow users of the
>>> ClientSideWindowHandler to
>>>>> specify
>>>>>>> if
>>>>>>>>>> it should get applied per Request
>>>>>>>>>> (EXTCDI-240) Enhance
> ClientSideWindowHandler -
>>> remove
>>>>> flickering,
>>>>>>> etc
>>>>>>>>>>
>>>>>>>>>> Just one question: if the flickering
> problem was
>>> fixed on
>>>>> the
>>>>>>> current
>>>>>>>>>> solution done on EXTCDI, it is still
> necessary to
>>> create
>>>>> an
>>>>>>>>>> implementation inside myfaces core for
> windowId?
>>> This
>>>>> problem is on
>>>>>>> my
>>>>>>>>>> list of things to do, so it is better to
> ask
>>> first.
>>>>>>>>>>
>>>>>>>>>> regards,
>>>>>>>>>>
>>>>>>>>>> Leonardo Uribe
>>>>>>>>>>
>>>>>>>>> Good question, I guess we need something for
> WindowID
>>> handling
>>>>> for
>>>>>>> jsf2.2
>>>>>>>>> especially given in hindisght of what is
> planned for
>>> 2.2
>>>>> according to
>>>>>>> Ed
>>>>>>>>> Burns blog but the final answer for now is
> up to the
>>> CODI
>>>>> guys.
>>>>>>>>>
>>>>>>>>> Werner
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jakob Korherr
>>>>>
>>>>> blog: http://www.jakobk.com
>>>>> twitter: http://twitter.com/jakobkorherr
>>>>> work: http://www.irian.at
>>>>>
>>>>
>>>
>>
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Leonardo Uribe <lu...@gmail.com>.
2011/11/18 Mark Struberg <st...@yahoo.de>:
>> 1. To implement 2. it is necessary
>> a "requestId". MyFaces FlashImpl uses a counter and store its value inside
>> a cookie
>
> The trick could be the same which I do atm for the 2nd windowId request: Each URL always contains the windowId, and the cookie name also contains the windowId. This way 2 tabs cannot get the same cookie...
>
Yes, the idea could be to generate a request id together with the
windowId (in fact the proposal in the wiki mentions generate a
windowId and a requestId). Since the spec already provide an interface
to implement Flash scope (javax.faces.context.Flash abstract class),
there is no need to create another interface to fill the gap between
requestId management and Flash object, instead create an alternate
Flash scope object, reusing the original code and fixing the parts
related to cookie management with the alternate code. Note Flash scope
"changes" before render response phase, so you need to do some
handling between the current and the next requestId.
> LieGrue,
> strub
>
>
> ----- Original Message -----
>> From: Leonardo Uribe <lu...@gmail.com>
>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg <st...@yahoo.de>
>> Cc:
>> Sent: Friday, November 18, 2011 11:08 PM
>> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>>
>> Hi
>>
>> MS>> The ClientSideWindowHandler solution in CODI looks good so far, but
>> there
>> MS>> is still a lot to do.
>>
>> MS>> And like every technology, it has it's pros and cons...
>>
>> MS>> What do you think about making the windowId provider pluggable in
>> MyFaces
>> MS>> core first?
>>
>> I have been thinking about every possible option we have for implement this and
>> the conclusion was the best way is make something like the hack done in CODI or
>> a "variant" of it, like the one described on:
>>
>> http://wiki.apache.org/myfaces/Drafts/WindowId
>>
>> (Mixed approach of the first prototype)
>>
>> From the point of view of MyFaces Core, any solution should be bound to the
>> renderkit in some way. So, windowId concept has sense to include it on the spec
>> but its implementation should be done according to the renderkit. If the
>> renderkit handles html, do the hack proposed but if is xml, do other thing
>> and so on. It sounds like something to do outside MyFaces Core. Basically the
>> problem is how to create an interface about something that could require
>> changes over the renderkit/viewhandler?.
>>
>> Maybe we can minimize the problem, and provide an interface like this:
>>
>> public interface WindowIdRenderKitAware
>> {
>> public String getCurrentWindowId(FacesContext facesContext);
>> }
>>
>> But let the details about how to "plug" all pieces inside CODI.
>> MyFaces Core
>> just offer the "integration point", and the default algorithm just do
>> what is
>> doing right now. Who should implement this interface? the renderkit, even if
>> in the implementation the value can be stored inside FacesContext attribute
>> map or request map. There exists a RenderKitWrapper interface, so it is
>> easy to create a wrapper for default HTML_BASIC renderkit or any other and
>> then scan through the wrappers and the first one implementing the interface
>> will be the choosen.
>>
>> MS>> The REAL problem with JSF and multiple tabs is that once you open 2
>> tabs
>> MS>> and click in 1 of them often enough, then you will destroy the state
>> of
>> MS>> the view in the other tab as well somewhen. Usually after 20 requests
>> MS>> (default).
>>
>> There are two points where this logic could be useful inside MyFaces Core :
>>
>> 1. Server side state
>> 2. Flash scope
>>
>> But in practice the only really relevant is 1. To implement 2. it is necessary
>> a "requestId". MyFaces FlashImpl uses a counter and store its value
>> inside
>> a cookie. To fix this scope properly, the best is create a ExternalContext
>> wrapper and provide and alternate Flash object, but that sounds like something
>> that can be done outside MyFaces Core. If you are using CDI scopes, it sounds
>> reasonable to provide an alternate Flash scope in CODI.
>>
>> If we can just modify the logic inside server side state to include
>> "windowId"
>> concept, it will be enough.
>>
>> MS>> To come over this, we need to store the n last views not only per
>> session,
>> MS>> but also per browser tab (==windowId).
>> MS>> Of course, there can be lots of fancy stuff done to detect closed
>> tabs,
>> MS>> etc. But all this is much more stable if we really have the
>> opportunity
>> MS>> to distinguish between tabs. We can e.g. also introduce a
>> configuration
>> MS>> for maximum allowed tabs, to reduce memory blasting.
>>
>> Really since all state is stored in session, if the session is invalidated all
>> tabs are removed from memory. Basically we already have params for max number
>> of sessions and max number of logical sessions (which in fact can be seen
>> as "tabs"). So what we have right now is ok, we just need to include
>> windowId
>> concept into the logic and that's it.
>>
>> MS>> All this is actually completely independent of how the windowId
>> get's
>> MS>> created and checked imo.
>>
>> Yes, that's right.
>>
>> MS>> I now tend to do the following (just atm creating a better playground
>> MS>> example in CODI + hack on the ClientSideWindowHandler):
>> MS>>
>> MS>> a.) the cookie thingy is pretty bääh. it just doesn't work if a
>> user clicks
>> MS>> quickly through a list and opens lots of 'detail pages' on
>> different tabs
>> MS>> within 2 seconds.
>> MS>>
>> MS>> b.) it's currently a 'one or the other' thingy, and I now
>> thought about
>> MS>> combining the lazyWindowIdDropp.js and the current windowhandler.js
>> MS>>
>> MS>> My current research goes into the direction of
>> MS>>
>> MS>> 1.) always adding the windowId to each and every link and transport
>> the
>> MS>> windowId only via this parameter.
>> MS>>
>> MS>> 2.) For HTML5-browsers (detected via UserAgent) I render the
>> MS>> windowhandler.html intermediate page which does all the fancy stuff
>> of
>> MS>> dynamically applying the old DOM on the intermediate page, etc. For
>> other
>> MS>> clients we rely on the lazyWindowId script.
>>
>> Ok, sounds promising. So, I'll focus on how to fix the logic for myfaces
>> core server side state saving
>> (org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the alternative
>> proposed in this mail (WindowIdRenderKitAware interface, and then use a
>> RenderKit wrapper).
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>> I now tend to do the following (just atm creating a better playground
>> example in CODI + hack on the ClientSideWindowHandler):
>>>
>>> a.) the cookie thingy is pretty bääh. it just doesn't work if a user
>> clicks quickly through a list and opens lots of 'detail pages' on
>> different tabs within 2 seconds.
>>>
>>> b.) it's currently a 'one or the other' thingy, and I now
>> thought about combining the lazyWindowIdDropp.js and the current
>> windowhandler.js
>>>
>>> My current research goes into the direction of
>>>
>>> 1.) always adding the windowId to each and every link and transport the
>> windowId only via this parameter.
>>>
>>> 2.) For HTML5-browsers (detected via UserAgent) I render the
>> windowhandler.html intermediate page which does all the fancy stuff of
>> dynamically applying the old DOM on the intermediate page, etc. For other
>> clients we rely on the lazyWindowId script.
>>>
>>> Any help is welcome.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Jakob Korherr <ja...@gmail.com>
>>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg
>> <st...@yahoo.de>
>>>> Cc:
>>>> Sent: Friday, November 18, 2011 2:23 PM
>>>> Subject: Re: [core extcdi] is required to create another proposal about
>> windowId?
>>>>
>>>> Hi,
>>>>
>>>>> PS: btw, a PhD student in my institute made me aware of a trick
>> with the
>>>> browser history. I think Jakob also already researched in this
>> direction:
>>>>>
>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>>> This mechanism does only 1 GET request (mine does 2), but with
>> pure AJAX
>>>> you imo cannot fully replace the header once the window is fully
>> loaded. Thus
>>>> you cannot easily handle dynamically loaded CSS, background images, etc
>> with
>>>> this approach.
>>>>
>>>> Yeap, I did some research in this area and also came across
>>>> https://github.com/balupton/history.js (there are actually a hand full
>>>> of projects on github which accomplish the same thing). This sure is a
>>>> very good way of implementing a rich web 2.0 application with working
>>>> history (--> back button), facebook and twitter are surely the most
>>>> famous examples of this technique.
>>>>
>>>> However, Mark is right: doing this, you will end up in a lot of
>>>> browser related problems when it comes to dynamic loading of
>>>> stylesheets, scripts, etc.. Facebook and twitter managed to get this
>>>> working for their purposes, but IMO it is not that easy for a standard
>>>> JSF developer/architect.
>>>>
>>>> Regards,
>>>> Jakob
>>>>
>>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>>> Hi!
>>>>>
>>>>> The ClientSideWindowHandler solution in CODI looks good so far,
>> but there
>>>> is still a lot to do.
>>>>>
>>>>> And like every technology, it has it's pros and cons...
>>>>>
>>>>> What do you think about making the windowId provider pluggable in
>> MyFaces
>>>> core first?
>>>>>
>>>>> The REAL problem with JSF and multiple tabs is that once you open
>> 2 tabs
>>>> and click in 1 of them often enough, then you will destroy the state of
>> the view
>>>> in the other tab as well somewhen. Usually after 20 requests (default).
>>>>>
>>>>> To come over this, we need to store the n last views not only per
>> session,
>>>> but also per browser tab (==windowId).
>>>>> Of course, there can be lots of fancy stuff done to detect closed
>> tabs,
>>>> etc. But all this is much more stable if we really have the opportunity
>> to
>>>> distinguish between tabs. We can e.g. also introduce a configuration
>> for maximum
>>>> allowed tabs, to reduce memory blasting.
>>>>>
>>>>> All this is actually completely independent of how the windowId
>> get's
>>>> created and checked imo.
>>>>>
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>> PS: btw, a PhD student in my institute made me aware of a trick
>> with the
>>>> browser history. I think Jakob also already researched in this
>> direction:
>>>>>
>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>>> This mechanism does only 1 GET request (mine does 2), but with
>> pure AJAX
>>>> you imo cannot fully replace the header once the window is fully
>> loaded. Thus
>>>> you cannot easily handle dynamically loaded CSS, background images, etc
>> with
>>>> this approach.
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: Leonardo Uribe <lu...@gmail.com>
>>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>>> Cc:
>>>>>> Sent: Thursday, November 17, 2011 9:39 PM
>>>>>> Subject: Re: [core extcdi] is required to create another
>> proposal about
>>>> windowId?
>>>>>>
>>>>>> Hi Gerhard
>>>>>>
>>>>>> Ok, good to know that. I'll work on a solution based on
>> the
>>>> previous
>>>>>> discussions about it to have more options in this case.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Leonardo Uribe
>>>>>>
>>>>>> 2011/11/17 Gerhard Petracek
>> <ge...@gmail.com>:
>>>>>>> hi leo,
>>>>>>>
>>>>>>> as soon as the new approach works, we can suggest it for
>> jsf 2.2.
>>>>>>> however, since it's only compatible with html5, we
>> have to
>>>> suggest a
>>>>>>> 2nd approach (e.g. the default behaviour of codi).
>>>>>>>
>>>>>>> regards,
>>>>>>> gerhard
>>>>>>>
>>>>>>> http://www.irian.at
>>>>>>>
>>>>>>> Your JSF powerhouse -
>>>>>>> JSF Consulting, Development and
>>>>>>> Courses in English and German
>>>>>>>
>>>>>>> Professional Support for Apache MyFaces
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2011/11/17 Werner Punz <we...@gmail.com>:
>>>>>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> In the last days there was some work in these
>> issues:
>>>>>>>>>
>>>>>>>>> (EXTCDI-242) improve ClientSideWindowHandler
>> windowId
>>>> passing via
>>>>>> cookie
>>>>>>>>> (EXTCDI-241) Allow users of the
>> ClientSideWindowHandler to
>>>> specify
>>>>>> if
>>>>>>>>> it should get applied per Request
>>>>>>>>> (EXTCDI-240) Enhance ClientSideWindowHandler -
>> remove
>>>> flickering,
>>>>>> etc
>>>>>>>>>
>>>>>>>>> Just one question: if the flickering problem was
>> fixed on
>>>> the
>>>>>> current
>>>>>>>>> solution done on EXTCDI, it is still necessary to
>> create
>>>> an
>>>>>>>>> implementation inside myfaces core for windowId?
>> This
>>>> problem is on
>>>>>> my
>>>>>>>>> list of things to do, so it is better to ask
>> first.
>>>>>>>>>
>>>>>>>>> regards,
>>>>>>>>>
>>>>>>>>> Leonardo Uribe
>>>>>>>>>
>>>>>>>> Good question, I guess we need something for WindowID
>> handling
>>>> for
>>>>>> jsf2.2
>>>>>>>> especially given in hindisght of what is planned for
>> 2.2
>>>> according to
>>>>>> Ed
>>>>>>>> Burns blog but the final answer for now is up to the
>> CODI
>>>> guys.
>>>>>>>>
>>>>>>>> Werner
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jakob Korherr
>>>>
>>>> blog: http://www.jakobk.com
>>>> twitter: http://twitter.com/jakobkorherr
>>>> work: http://www.irian.at
>>>>
>>>
>>
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Mark Struberg <st...@yahoo.de>.
> 1. To implement 2. it is necessary
> a "requestId". MyFaces FlashImpl uses a counter and store its value inside
> a cookie
The trick could be the same which I do atm for the 2nd windowId request: Each URL always contains the windowId, and the cookie name also contains the windowId. This way 2 tabs cannot get the same cookie...
LieGrue,
strub
----- Original Message -----
> From: Leonardo Uribe <lu...@gmail.com>
> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Friday, November 18, 2011 11:08 PM
> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>
> Hi
>
> MS>> The ClientSideWindowHandler solution in CODI looks good so far, but
> there
> MS>> is still a lot to do.
>
> MS>> And like every technology, it has it's pros and cons...
>
> MS>> What do you think about making the windowId provider pluggable in
> MyFaces
> MS>> core first?
>
> I have been thinking about every possible option we have for implement this and
> the conclusion was the best way is make something like the hack done in CODI or
> a "variant" of it, like the one described on:
>
> http://wiki.apache.org/myfaces/Drafts/WindowId
>
> (Mixed approach of the first prototype)
>
> From the point of view of MyFaces Core, any solution should be bound to the
> renderkit in some way. So, windowId concept has sense to include it on the spec
> but its implementation should be done according to the renderkit. If the
> renderkit handles html, do the hack proposed but if is xml, do other thing
> and so on. It sounds like something to do outside MyFaces Core. Basically the
> problem is how to create an interface about something that could require
> changes over the renderkit/viewhandler?.
>
> Maybe we can minimize the problem, and provide an interface like this:
>
> public interface WindowIdRenderKitAware
> {
> public String getCurrentWindowId(FacesContext facesContext);
> }
>
> But let the details about how to "plug" all pieces inside CODI.
> MyFaces Core
> just offer the "integration point", and the default algorithm just do
> what is
> doing right now. Who should implement this interface? the renderkit, even if
> in the implementation the value can be stored inside FacesContext attribute
> map or request map. There exists a RenderKitWrapper interface, so it is
> easy to create a wrapper for default HTML_BASIC renderkit or any other and
> then scan through the wrappers and the first one implementing the interface
> will be the choosen.
>
> MS>> The REAL problem with JSF and multiple tabs is that once you open 2
> tabs
> MS>> and click in 1 of them often enough, then you will destroy the state
> of
> MS>> the view in the other tab as well somewhen. Usually after 20 requests
> MS>> (default).
>
> There are two points where this logic could be useful inside MyFaces Core :
>
> 1. Server side state
> 2. Flash scope
>
> But in practice the only really relevant is 1. To implement 2. it is necessary
> a "requestId". MyFaces FlashImpl uses a counter and store its value
> inside
> a cookie. To fix this scope properly, the best is create a ExternalContext
> wrapper and provide and alternate Flash object, but that sounds like something
> that can be done outside MyFaces Core. If you are using CDI scopes, it sounds
> reasonable to provide an alternate Flash scope in CODI.
>
> If we can just modify the logic inside server side state to include
> "windowId"
> concept, it will be enough.
>
> MS>> To come over this, we need to store the n last views not only per
> session,
> MS>> but also per browser tab (==windowId).
> MS>> Of course, there can be lots of fancy stuff done to detect closed
> tabs,
> MS>> etc. But all this is much more stable if we really have the
> opportunity
> MS>> to distinguish between tabs. We can e.g. also introduce a
> configuration
> MS>> for maximum allowed tabs, to reduce memory blasting.
>
> Really since all state is stored in session, if the session is invalidated all
> tabs are removed from memory. Basically we already have params for max number
> of sessions and max number of logical sessions (which in fact can be seen
> as "tabs"). So what we have right now is ok, we just need to include
> windowId
> concept into the logic and that's it.
>
> MS>> All this is actually completely independent of how the windowId
> get's
> MS>> created and checked imo.
>
> Yes, that's right.
>
> MS>> I now tend to do the following (just atm creating a better playground
> MS>> example in CODI + hack on the ClientSideWindowHandler):
> MS>>
> MS>> a.) the cookie thingy is pretty bääh. it just doesn't work if a
> user clicks
> MS>> quickly through a list and opens lots of 'detail pages' on
> different tabs
> MS>> within 2 seconds.
> MS>>
> MS>> b.) it's currently a 'one or the other' thingy, and I now
> thought about
> MS>> combining the lazyWindowIdDropp.js and the current windowhandler.js
> MS>>
> MS>> My current research goes into the direction of
> MS>>
> MS>> 1.) always adding the windowId to each and every link and transport
> the
> MS>> windowId only via this parameter.
> MS>>
> MS>> 2.) For HTML5-browsers (detected via UserAgent) I render the
> MS>> windowhandler.html intermediate page which does all the fancy stuff
> of
> MS>> dynamically applying the old DOM on the intermediate page, etc. For
> other
> MS>> clients we rely on the lazyWindowId script.
>
> Ok, sounds promising. So, I'll focus on how to fix the logic for myfaces
> core server side state saving
> (org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the alternative
> proposed in this mail (WindowIdRenderKitAware interface, and then use a
> RenderKit wrapper).
>
> regards,
>
> Leonardo Uribe
>
> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>> I now tend to do the following (just atm creating a better playground
> example in CODI + hack on the ClientSideWindowHandler):
>>
>> a.) the cookie thingy is pretty bääh. it just doesn't work if a user
> clicks quickly through a list and opens lots of 'detail pages' on
> different tabs within 2 seconds.
>>
>> b.) it's currently a 'one or the other' thingy, and I now
> thought about combining the lazyWindowIdDropp.js and the current
> windowhandler.js
>>
>> My current research goes into the direction of
>>
>> 1.) always adding the windowId to each and every link and transport the
> windowId only via this parameter.
>>
>> 2.) For HTML5-browsers (detected via UserAgent) I render the
> windowhandler.html intermediate page which does all the fancy stuff of
> dynamically applying the old DOM on the intermediate page, etc. For other
> clients we rely on the lazyWindowId script.
>>
>> Any help is welcome.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Jakob Korherr <ja...@gmail.com>
>>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg
> <st...@yahoo.de>
>>> Cc:
>>> Sent: Friday, November 18, 2011 2:23 PM
>>> Subject: Re: [core extcdi] is required to create another proposal about
> windowId?
>>>
>>> Hi,
>>>
>>>> PS: btw, a PhD student in my institute made me aware of a trick
> with the
>>> browser history. I think Jakob also already researched in this
> direction:
>>>>
> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>> This mechanism does only 1 GET request (mine does 2), but with
> pure AJAX
>>> you imo cannot fully replace the header once the window is fully
> loaded. Thus
>>> you cannot easily handle dynamically loaded CSS, background images, etc
> with
>>> this approach.
>>>
>>> Yeap, I did some research in this area and also came across
>>> https://github.com/balupton/history.js (there are actually a hand full
>>> of projects on github which accomplish the same thing). This sure is a
>>> very good way of implementing a rich web 2.0 application with working
>>> history (--> back button), facebook and twitter are surely the most
>>> famous examples of this technique.
>>>
>>> However, Mark is right: doing this, you will end up in a lot of
>>> browser related problems when it comes to dynamic loading of
>>> stylesheets, scripts, etc.. Facebook and twitter managed to get this
>>> working for their purposes, but IMO it is not that easy for a standard
>>> JSF developer/architect.
>>>
>>> Regards,
>>> Jakob
>>>
>>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>>> Hi!
>>>>
>>>> The ClientSideWindowHandler solution in CODI looks good so far,
> but there
>>> is still a lot to do.
>>>>
>>>> And like every technology, it has it's pros and cons...
>>>>
>>>> What do you think about making the windowId provider pluggable in
> MyFaces
>>> core first?
>>>>
>>>> The REAL problem with JSF and multiple tabs is that once you open
> 2 tabs
>>> and click in 1 of them often enough, then you will destroy the state of
> the view
>>> in the other tab as well somewhen. Usually after 20 requests (default).
>>>>
>>>> To come over this, we need to store the n last views not only per
> session,
>>> but also per browser tab (==windowId).
>>>> Of course, there can be lots of fancy stuff done to detect closed
> tabs,
>>> etc. But all this is much more stable if we really have the opportunity
> to
>>> distinguish between tabs. We can e.g. also introduce a configuration
> for maximum
>>> allowed tabs, to reduce memory blasting.
>>>>
>>>> All this is actually completely independent of how the windowId
> get's
>>> created and checked imo.
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>> PS: btw, a PhD student in my institute made me aware of a trick
> with the
>>> browser history. I think Jakob also already researched in this
> direction:
>>>>
> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>>> This mechanism does only 1 GET request (mine does 2), but with
> pure AJAX
>>> you imo cannot fully replace the header once the window is fully
> loaded. Thus
>>> you cannot easily handle dynamically loaded CSS, background images, etc
> with
>>> this approach.
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: Leonardo Uribe <lu...@gmail.com>
>>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>>> Cc:
>>>>> Sent: Thursday, November 17, 2011 9:39 PM
>>>>> Subject: Re: [core extcdi] is required to create another
> proposal about
>>> windowId?
>>>>>
>>>>> Hi Gerhard
>>>>>
>>>>> Ok, good to know that. I'll work on a solution based on
> the
>>> previous
>>>>> discussions about it to have more options in this case.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>> 2011/11/17 Gerhard Petracek
> <ge...@gmail.com>:
>>>>>> hi leo,
>>>>>>
>>>>>> as soon as the new approach works, we can suggest it for
> jsf 2.2.
>>>>>> however, since it's only compatible with html5, we
> have to
>>> suggest a
>>>>>> 2nd approach (e.g. the default behaviour of codi).
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>> http://www.irian.at
>>>>>>
>>>>>> Your JSF powerhouse -
>>>>>> JSF Consulting, Development and
>>>>>> Courses in English and German
>>>>>>
>>>>>> Professional Support for Apache MyFaces
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2011/11/17 Werner Punz <we...@gmail.com>:
>>>>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> In the last days there was some work in these
> issues:
>>>>>>>>
>>>>>>>> (EXTCDI-242) improve ClientSideWindowHandler
> windowId
>>> passing via
>>>>> cookie
>>>>>>>> (EXTCDI-241) Allow users of the
> ClientSideWindowHandler to
>>> specify
>>>>> if
>>>>>>>> it should get applied per Request
>>>>>>>> (EXTCDI-240) Enhance ClientSideWindowHandler -
> remove
>>> flickering,
>>>>> etc
>>>>>>>>
>>>>>>>> Just one question: if the flickering problem was
> fixed on
>>> the
>>>>> current
>>>>>>>> solution done on EXTCDI, it is still necessary to
> create
>>> an
>>>>>>>> implementation inside myfaces core for windowId?
> This
>>> problem is on
>>>>> my
>>>>>>>> list of things to do, so it is better to ask
> first.
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Leonardo Uribe
>>>>>>>>
>>>>>>> Good question, I guess we need something for WindowID
> handling
>>> for
>>>>> jsf2.2
>>>>>>> especially given in hindisght of what is planned for
> 2.2
>>> according to
>>>>> Ed
>>>>>>> Burns blog but the final answer for now is up to the
> CODI
>>> guys.
>>>>>>>
>>>>>>> Werner
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Jakob Korherr
>>>
>>> blog: http://www.jakobk.com
>>> twitter: http://twitter.com/jakobkorherr
>>> work: http://www.irian.at
>>>
>>
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
MS>> The ClientSideWindowHandler solution in CODI looks good so far, but there
MS>> is still a lot to do.
MS>> And like every technology, it has it's pros and cons...
MS>> What do you think about making the windowId provider pluggable in MyFaces
MS>> core first?
I have been thinking about every possible option we have for implement this and
the conclusion was the best way is make something like the hack done in CODI or
a "variant" of it, like the one described on:
http://wiki.apache.org/myfaces/Drafts/WindowId
(Mixed approach of the first prototype)
>From the point of view of MyFaces Core, any solution should be bound to the
renderkit in some way. So, windowId concept has sense to include it on the spec
but its implementation should be done according to the renderkit. If the
renderkit handles html, do the hack proposed but if is xml, do other thing
and so on. It sounds like something to do outside MyFaces Core. Basically the
problem is how to create an interface about something that could require
changes over the renderkit/viewhandler?.
Maybe we can minimize the problem, and provide an interface like this:
public interface WindowIdRenderKitAware
{
public String getCurrentWindowId(FacesContext facesContext);
}
But let the details about how to "plug" all pieces inside CODI. MyFaces Core
just offer the "integration point", and the default algorithm just do what is
doing right now. Who should implement this interface? the renderkit, even if
in the implementation the value can be stored inside FacesContext attribute
map or request map. There exists a RenderKitWrapper interface, so it is
easy to create a wrapper for default HTML_BASIC renderkit or any other and
then scan through the wrappers and the first one implementing the interface
will be the choosen.
MS>> The REAL problem with JSF and multiple tabs is that once you open 2 tabs
MS>> and click in 1 of them often enough, then you will destroy the state of
MS>> the view in the other tab as well somewhen. Usually after 20 requests
MS>> (default).
There are two points where this logic could be useful inside MyFaces Core :
1. Server side state
2. Flash scope
But in practice the only really relevant is 1. To implement 2. it is necessary
a "requestId". MyFaces FlashImpl uses a counter and store its value inside
a cookie. To fix this scope properly, the best is create a ExternalContext
wrapper and provide and alternate Flash object, but that sounds like something
that can be done outside MyFaces Core. If you are using CDI scopes, it sounds
reasonable to provide an alternate Flash scope in CODI.
If we can just modify the logic inside server side state to include "windowId"
concept, it will be enough.
MS>> To come over this, we need to store the n last views not only per session,
MS>> but also per browser tab (==windowId).
MS>> Of course, there can be lots of fancy stuff done to detect closed tabs,
MS>> etc. But all this is much more stable if we really have the opportunity
MS>> to distinguish between tabs. We can e.g. also introduce a configuration
MS>> for maximum allowed tabs, to reduce memory blasting.
Really since all state is stored in session, if the session is invalidated all
tabs are removed from memory. Basically we already have params for max number
of sessions and max number of logical sessions (which in fact can be seen
as "tabs"). So what we have right now is ok, we just need to include windowId
concept into the logic and that's it.
MS>> All this is actually completely independent of how the windowId get's
MS>> created and checked imo.
Yes, that's right.
MS>> I now tend to do the following (just atm creating a better playground
MS>> example in CODI + hack on the ClientSideWindowHandler):
MS>>
MS>> a.) the cookie thingy is pretty bääh. it just doesn't work if a
user clicks
MS>> quickly through a list and opens lots of 'detail pages' on different tabs
MS>> within 2 seconds.
MS>>
MS>> b.) it's currently a 'one or the other' thingy, and I now thought about
MS>> combining the lazyWindowIdDropp.js and the current windowhandler.js
MS>>
MS>> My current research goes into the direction of
MS>>
MS>> 1.) always adding the windowId to each and every link and transport the
MS>> windowId only via this parameter.
MS>>
MS>> 2.) For HTML5-browsers (detected via UserAgent) I render the
MS>> windowhandler.html intermediate page which does all the fancy stuff of
MS>> dynamically applying the old DOM on the intermediate page, etc. For other
MS>> clients we rely on the lazyWindowId script.
Ok, sounds promising. So, I'll focus on how to fix the logic for myfaces
core server side state saving
(org.apache.myfaces.renderkit.ServerSideStateCacheImpl), with the alternative
proposed in this mail (WindowIdRenderKitAware interface, and then use a
RenderKit wrapper).
regards,
Leonardo Uribe
2011/11/18 Mark Struberg <st...@yahoo.de>:
> I now tend to do the following (just atm creating a better playground example in CODI + hack on the ClientSideWindowHandler):
>
> a.) the cookie thingy is pretty bääh. it just doesn't work if a user clicks quickly through a list and opens lots of 'detail pages' on different tabs within 2 seconds.
>
> b.) it's currently a 'one or the other' thingy, and I now thought about combining the lazyWindowIdDropp.js and the current windowhandler.js
>
> My current research goes into the direction of
>
> 1.) always adding the windowId to each and every link and transport the windowId only via this parameter.
>
> 2.) For HTML5-browsers (detected via UserAgent) I render the windowhandler.html intermediate page which does all the fancy stuff of dynamically applying the old DOM on the intermediate page, etc. For other clients we rely on the lazyWindowId script.
>
> Any help is welcome.
>
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Jakob Korherr <ja...@gmail.com>
>> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg <st...@yahoo.de>
>> Cc:
>> Sent: Friday, November 18, 2011 2:23 PM
>> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>>
>> Hi,
>>
>>> PS: btw, a PhD student in my institute made me aware of a trick with the
>> browser history. I think Jakob also already researched in this direction:
>>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>> This mechanism does only 1 GET request (mine does 2), but with pure AJAX
>> you imo cannot fully replace the header once the window is fully loaded. Thus
>> you cannot easily handle dynamically loaded CSS, background images, etc with
>> this approach.
>>
>> Yeap, I did some research in this area and also came across
>> https://github.com/balupton/history.js (there are actually a hand full
>> of projects on github which accomplish the same thing). This sure is a
>> very good way of implementing a rich web 2.0 application with working
>> history (--> back button), facebook and twitter are surely the most
>> famous examples of this technique.
>>
>> However, Mark is right: doing this, you will end up in a lot of
>> browser related problems when it comes to dynamic loading of
>> stylesheets, scripts, etc.. Facebook and twitter managed to get this
>> working for their purposes, but IMO it is not that easy for a standard
>> JSF developer/architect.
>>
>> Regards,
>> Jakob
>>
>> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>>> Hi!
>>>
>>> The ClientSideWindowHandler solution in CODI looks good so far, but there
>> is still a lot to do.
>>>
>>> And like every technology, it has it's pros and cons...
>>>
>>> What do you think about making the windowId provider pluggable in MyFaces
>> core first?
>>>
>>> The REAL problem with JSF and multiple tabs is that once you open 2 tabs
>> and click in 1 of them often enough, then you will destroy the state of the view
>> in the other tab as well somewhen. Usually after 20 requests (default).
>>>
>>> To come over this, we need to store the n last views not only per session,
>> but also per browser tab (==windowId).
>>> Of course, there can be lots of fancy stuff done to detect closed tabs,
>> etc. But all this is much more stable if we really have the opportunity to
>> distinguish between tabs. We can e.g. also introduce a configuration for maximum
>> allowed tabs, to reduce memory blasting.
>>>
>>> All this is actually completely independent of how the windowId get's
>> created and checked imo.
>>>
>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: btw, a PhD student in my institute made me aware of a trick with the
>> browser history. I think Jakob also already researched in this direction:
>>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>>> This mechanism does only 1 GET request (mine does 2), but with pure AJAX
>> you imo cannot fully replace the header once the window is fully loaded. Thus
>> you cannot easily handle dynamically loaded CSS, background images, etc with
>> this approach.
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Leonardo Uribe <lu...@gmail.com>
>>>> To: MyFaces Development <de...@myfaces.apache.org>
>>>> Cc:
>>>> Sent: Thursday, November 17, 2011 9:39 PM
>>>> Subject: Re: [core extcdi] is required to create another proposal about
>> windowId?
>>>>
>>>> Hi Gerhard
>>>>
>>>> Ok, good to know that. I'll work on a solution based on the
>> previous
>>>> discussions about it to have more options in this case.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>> 2011/11/17 Gerhard Petracek <ge...@gmail.com>:
>>>>> hi leo,
>>>>>
>>>>> as soon as the new approach works, we can suggest it for jsf 2.2.
>>>>> however, since it's only compatible with html5, we have to
>> suggest a
>>>>> 2nd approach (e.g. the default behaviour of codi).
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>> http://www.irian.at
>>>>>
>>>>> Your JSF powerhouse -
>>>>> JSF Consulting, Development and
>>>>> Courses in English and German
>>>>>
>>>>> Professional Support for Apache MyFaces
>>>>>
>>>>>
>>>>>
>>>>> 2011/11/17 Werner Punz <we...@gmail.com>:
>>>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> In the last days there was some work in these issues:
>>>>>>>
>>>>>>> (EXTCDI-242) improve ClientSideWindowHandler windowId
>> passing via
>>>> cookie
>>>>>>> (EXTCDI-241) Allow users of the ClientSideWindowHandler to
>> specify
>>>> if
>>>>>>> it should get applied per Request
>>>>>>> (EXTCDI-240) Enhance ClientSideWindowHandler - remove
>> flickering,
>>>> etc
>>>>>>>
>>>>>>> Just one question: if the flickering problem was fixed on
>> the
>>>> current
>>>>>>> solution done on EXTCDI, it is still necessary to create
>> an
>>>>>>> implementation inside myfaces core for windowId? This
>> problem is on
>>>> my
>>>>>>> list of things to do, so it is better to ask first.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Leonardo Uribe
>>>>>>>
>>>>>> Good question, I guess we need something for WindowID handling
>> for
>>>> jsf2.2
>>>>>> especially given in hindisght of what is planned for 2.2
>> according to
>>>> Ed
>>>>>> Burns blog but the final answer for now is up to the CODI
>> guys.
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Jakob Korherr
>>
>> blog: http://www.jakobk.com
>> twitter: http://twitter.com/jakobkorherr
>> work: http://www.irian.at
>>
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Mark Struberg <st...@yahoo.de>.
I now tend to do the following (just atm creating a better playground example in CODI + hack on the ClientSideWindowHandler):
a.) the cookie thingy is pretty bääh. it just doesn't work if a user clicks quickly through a list and opens lots of 'detail pages' on different tabs within 2 seconds.
b.) it's currently a 'one or the other' thingy, and I now thought about combining the lazyWindowIdDropp.js and the current windowhandler.js
My current research goes into the direction of
1.) always adding the windowId to each and every link and transport the windowId only via this parameter.
2.) For HTML5-browsers (detected via UserAgent) I render the windowhandler.html intermediate page which does all the fancy stuff of dynamically applying the old DOM on the intermediate page, etc. For other clients we rely on the lazyWindowId script.
Any help is welcome.
LieGrue,
strub
----- Original Message -----
> From: Jakob Korherr <ja...@gmail.com>
> To: MyFaces Development <de...@myfaces.apache.org>; Mark Struberg <st...@yahoo.de>
> Cc:
> Sent: Friday, November 18, 2011 2:23 PM
> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>
> Hi,
>
>> PS: btw, a PhD student in my institute made me aware of a trick with the
> browser history. I think Jakob also already researched in this direction:
>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>> This mechanism does only 1 GET request (mine does 2), but with pure AJAX
> you imo cannot fully replace the header once the window is fully loaded. Thus
> you cannot easily handle dynamically loaded CSS, background images, etc with
> this approach.
>
> Yeap, I did some research in this area and also came across
> https://github.com/balupton/history.js (there are actually a hand full
> of projects on github which accomplish the same thing). This sure is a
> very good way of implementing a rich web 2.0 application with working
> history (--> back button), facebook and twitter are surely the most
> famous examples of this technique.
>
> However, Mark is right: doing this, you will end up in a lot of
> browser related problems when it comes to dynamic loading of
> stylesheets, scripts, etc.. Facebook and twitter managed to get this
> working for their purposes, but IMO it is not that easy for a standard
> JSF developer/architect.
>
> Regards,
> Jakob
>
> 2011/11/18 Mark Struberg <st...@yahoo.de>:
>> Hi!
>>
>> The ClientSideWindowHandler solution in CODI looks good so far, but there
> is still a lot to do.
>>
>> And like every technology, it has it's pros and cons...
>>
>> What do you think about making the windowId provider pluggable in MyFaces
> core first?
>>
>> The REAL problem with JSF and multiple tabs is that once you open 2 tabs
> and click in 1 of them often enough, then you will destroy the state of the view
> in the other tab as well somewhen. Usually after 20 requests (default).
>>
>> To come over this, we need to store the n last views not only per session,
> but also per browser tab (==windowId).
>> Of course, there can be lots of fancy stuff done to detect closed tabs,
> etc. But all this is much more stable if we really have the opportunity to
> distinguish between tabs. We can e.g. also introduce a configuration for maximum
> allowed tabs, to reduce memory blasting.
>>
>> All this is actually completely independent of how the windowId get's
> created and checked imo.
>>
>>
>> LieGrue,
>> strub
>>
>> PS: btw, a PhD student in my institute made me aware of a trick with the
> browser history. I think Jakob also already researched in this direction:
>> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
>> This mechanism does only 1 GET request (mine does 2), but with pure AJAX
> you imo cannot fully replace the header once the window is fully loaded. Thus
> you cannot easily handle dynamically loaded CSS, background images, etc with
> this approach.
>>
>>
>>
>> ----- Original Message -----
>>> From: Leonardo Uribe <lu...@gmail.com>
>>> To: MyFaces Development <de...@myfaces.apache.org>
>>> Cc:
>>> Sent: Thursday, November 17, 2011 9:39 PM
>>> Subject: Re: [core extcdi] is required to create another proposal about
> windowId?
>>>
>>> Hi Gerhard
>>>
>>> Ok, good to know that. I'll work on a solution based on the
> previous
>>> discussions about it to have more options in this case.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/11/17 Gerhard Petracek <ge...@gmail.com>:
>>>> hi leo,
>>>>
>>>> as soon as the new approach works, we can suggest it for jsf 2.2.
>>>> however, since it's only compatible with html5, we have to
> suggest a
>>>> 2nd approach (e.g. the default behaviour of codi).
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>> http://www.irian.at
>>>>
>>>> Your JSF powerhouse -
>>>> JSF Consulting, Development and
>>>> Courses in English and German
>>>>
>>>> Professional Support for Apache MyFaces
>>>>
>>>>
>>>>
>>>> 2011/11/17 Werner Punz <we...@gmail.com>:
>>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> In the last days there was some work in these issues:
>>>>>>
>>>>>> (EXTCDI-242) improve ClientSideWindowHandler windowId
> passing via
>>> cookie
>>>>>> (EXTCDI-241) Allow users of the ClientSideWindowHandler to
> specify
>>> if
>>>>>> it should get applied per Request
>>>>>> (EXTCDI-240) Enhance ClientSideWindowHandler - remove
> flickering,
>>> etc
>>>>>>
>>>>>> Just one question: if the flickering problem was fixed on
> the
>>> current
>>>>>> solution done on EXTCDI, it is still necessary to create
> an
>>>>>> implementation inside myfaces core for windowId? This
> problem is on
>>> my
>>>>>> list of things to do, so it is better to ask first.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Leonardo Uribe
>>>>>>
>>>>> Good question, I guess we need something for WindowID handling
> for
>>> jsf2.2
>>>>> especially given in hindisght of what is planned for 2.2
> according to
>>> Ed
>>>>> Burns blog but the final answer for now is up to the CODI
> guys.
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> --
> Jakob Korherr
>
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Jakob Korherr <ja...@gmail.com>.
Hi,
> PS: btw, a PhD student in my institute made me aware of a trick with the browser history. I think Jakob also already researched in this direction:
> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
> This mechanism does only 1 GET request (mine does 2), but with pure AJAX you imo cannot fully replace the header once the window is fully loaded. Thus you cannot easily handle dynamically loaded CSS, background images, etc with this approach.
Yeap, I did some research in this area and also came across
https://github.com/balupton/history.js (there are actually a hand full
of projects on github which accomplish the same thing). This sure is a
very good way of implementing a rich web 2.0 application with working
history (--> back button), facebook and twitter are surely the most
famous examples of this technique.
However, Mark is right: doing this, you will end up in a lot of
browser related problems when it comes to dynamic loading of
stylesheets, scripts, etc.. Facebook and twitter managed to get this
working for their purposes, but IMO it is not that easy for a standard
JSF developer/architect.
Regards,
Jakob
2011/11/18 Mark Struberg <st...@yahoo.de>:
> Hi!
>
> The ClientSideWindowHandler solution in CODI looks good so far, but there is still a lot to do.
>
> And like every technology, it has it's pros and cons...
>
> What do you think about making the windowId provider pluggable in MyFaces core first?
>
> The REAL problem with JSF and multiple tabs is that once you open 2 tabs and click in 1 of them often enough, then you will destroy the state of the view in the other tab as well somewhen. Usually after 20 requests (default).
>
> To come over this, we need to store the n last views not only per session, but also per browser tab (==windowId).
> Of course, there can be lots of fancy stuff done to detect closed tabs, etc. But all this is much more stable if we really have the opportunity to distinguish between tabs. We can e.g. also introduce a configuration for maximum allowed tabs, to reduce memory blasting.
>
> All this is actually completely independent of how the windowId get's created and checked imo.
>
>
> LieGrue,
> strub
>
> PS: btw, a PhD student in my institute made me aware of a trick with the browser history. I think Jakob also already researched in this direction:
> https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
> This mechanism does only 1 GET request (mine does 2), but with pure AJAX you imo cannot fully replace the header once the window is fully loaded. Thus you cannot easily handle dynamically loaded CSS, background images, etc with this approach.
>
>
>
> ----- Original Message -----
>> From: Leonardo Uribe <lu...@gmail.com>
>> To: MyFaces Development <de...@myfaces.apache.org>
>> Cc:
>> Sent: Thursday, November 17, 2011 9:39 PM
>> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>>
>> Hi Gerhard
>>
>> Ok, good to know that. I'll work on a solution based on the previous
>> discussions about it to have more options in this case.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/11/17 Gerhard Petracek <ge...@gmail.com>:
>>> hi leo,
>>>
>>> as soon as the new approach works, we can suggest it for jsf 2.2.
>>> however, since it's only compatible with html5, we have to suggest a
>>> 2nd approach (e.g. the default behaviour of codi).
>>>
>>> regards,
>>> gerhard
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>>
>>>
>>> 2011/11/17 Werner Punz <we...@gmail.com>:
>>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>>
>>>>> Hi
>>>>>
>>>>> In the last days there was some work in these issues:
>>>>>
>>>>> (EXTCDI-242) improve ClientSideWindowHandler windowId passing via
>> cookie
>>>>> (EXTCDI-241) Allow users of the ClientSideWindowHandler to specify
>> if
>>>>> it should get applied per Request
>>>>> (EXTCDI-240) Enhance ClientSideWindowHandler - remove flickering,
>> etc
>>>>>
>>>>> Just one question: if the flickering problem was fixed on the
>> current
>>>>> solution done on EXTCDI, it is still necessary to create an
>>>>> implementation inside myfaces core for windowId? This problem is on
>> my
>>>>> list of things to do, so it is better to ask first.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>> Good question, I guess we need something for WindowID handling for
>> jsf2.2
>>>> especially given in hindisght of what is planned for 2.2 according to
>> Ed
>>>> Burns blog but the final answer for now is up to the CODI guys.
>>>>
>>>> Werner
>>>>
>>>>
>>>>
>>>
>>
>
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Mark Struberg <st...@yahoo.de>.
Hi!
The ClientSideWindowHandler solution in CODI looks good so far, but there is still a lot to do.
And like every technology, it has it's pros and cons...
What do you think about making the windowId provider pluggable in MyFaces core first?
The REAL problem with JSF and multiple tabs is that once you open 2 tabs and click in 1 of them often enough, then you will destroy the state of the view in the other tab as well somewhen. Usually after 20 requests (default).
To come over this, we need to store the n last views not only per session, but also per browser tab (==windowId).
Of course, there can be lots of fancy stuff done to detect closed tabs, etc. But all this is much more stable if we really have the opportunity to distinguish between tabs. We can e.g. also introduce a configuration for maximum allowed tabs, to reduce memory blasting.
All this is actually completely independent of how the windowId get's created and checked imo.
LieGrue,
strub
PS: btw, a PhD student in my institute made me aware of a trick with the browser history. I think Jakob also already researched in this direction:
https://github.com/balupton/history.js/wiki/Intelligent-State-Handling
This mechanism does only 1 GET request (mine does 2), but with pure AJAX you imo cannot fully replace the header once the window is fully loaded. Thus you cannot easily handle dynamically loaded CSS, background images, etc with this approach.
----- Original Message -----
> From: Leonardo Uribe <lu...@gmail.com>
> To: MyFaces Development <de...@myfaces.apache.org>
> Cc:
> Sent: Thursday, November 17, 2011 9:39 PM
> Subject: Re: [core extcdi] is required to create another proposal about windowId?
>
> Hi Gerhard
>
> Ok, good to know that. I'll work on a solution based on the previous
> discussions about it to have more options in this case.
>
> regards,
>
> Leonardo Uribe
>
> 2011/11/17 Gerhard Petracek <ge...@gmail.com>:
>> hi leo,
>>
>> as soon as the new approach works, we can suggest it for jsf 2.2.
>> however, since it's only compatible with html5, we have to suggest a
>> 2nd approach (e.g. the default behaviour of codi).
>>
>> regards,
>> gerhard
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>> 2011/11/17 Werner Punz <we...@gmail.com>:
>>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>>
>>>> Hi
>>>>
>>>> In the last days there was some work in these issues:
>>>>
>>>> (EXTCDI-242) improve ClientSideWindowHandler windowId passing via
> cookie
>>>> (EXTCDI-241) Allow users of the ClientSideWindowHandler to specify
> if
>>>> it should get applied per Request
>>>> (EXTCDI-240) Enhance ClientSideWindowHandler - remove flickering,
> etc
>>>>
>>>> Just one question: if the flickering problem was fixed on the
> current
>>>> solution done on EXTCDI, it is still necessary to create an
>>>> implementation inside myfaces core for windowId? This problem is on
> my
>>>> list of things to do, so it is better to ask first.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>> Good question, I guess we need something for WindowID handling for
> jsf2.2
>>> especially given in hindisght of what is planned for 2.2 according to
> Ed
>>> Burns blog but the final answer for now is up to the CODI guys.
>>>
>>> Werner
>>>
>>>
>>>
>>
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi Gerhard
Ok, good to know that. I'll work on a solution based on the previous
discussions about it to have more options in this case.
regards,
Leonardo Uribe
2011/11/17 Gerhard Petracek <ge...@gmail.com>:
> hi leo,
>
> as soon as the new approach works, we can suggest it for jsf 2.2.
> however, since it's only compatible with html5, we have to suggest a
> 2nd approach (e.g. the default behaviour of codi).
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
> 2011/11/17 Werner Punz <we...@gmail.com>:
>> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>>
>>> Hi
>>>
>>> In the last days there was some work in these issues:
>>>
>>> (EXTCDI-242) improve ClientSideWindowHandler windowId passing via cookie
>>> (EXTCDI-241) Allow users of the ClientSideWindowHandler to specify if
>>> it should get applied per Request
>>> (EXTCDI-240) Enhance ClientSideWindowHandler - remove flickering, etc
>>>
>>> Just one question: if the flickering problem was fixed on the current
>>> solution done on EXTCDI, it is still necessary to create an
>>> implementation inside myfaces core for windowId? This problem is on my
>>> list of things to do, so it is better to ask first.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>> Good question, I guess we need something for WindowID handling for jsf2.2
>> especially given in hindisght of what is planned for 2.2 according to Ed
>> Burns blog but the final answer for now is up to the CODI guys.
>>
>> Werner
>>
>>
>>
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Gerhard Petracek <ge...@gmail.com>.
hi leo,
as soon as the new approach works, we can suggest it for jsf 2.2.
however, since it's only compatible with html5, we have to suggest a
2nd approach (e.g. the default behaviour of codi).
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/11/17 Werner Punz <we...@gmail.com>:
> Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
>>
>> Hi
>>
>> In the last days there was some work in these issues:
>>
>> (EXTCDI-242) improve ClientSideWindowHandler windowId passing via cookie
>> (EXTCDI-241) Allow users of the ClientSideWindowHandler to specify if
>> it should get applied per Request
>> (EXTCDI-240) Enhance ClientSideWindowHandler - remove flickering, etc
>>
>> Just one question: if the flickering problem was fixed on the current
>> solution done on EXTCDI, it is still necessary to create an
>> implementation inside myfaces core for windowId? This problem is on my
>> list of things to do, so it is better to ask first.
>>
>> regards,
>>
>> Leonardo Uribe
>>
> Good question, I guess we need something for WindowID handling for jsf2.2
> especially given in hindisght of what is planned for 2.2 according to Ed
> Burns blog but the final answer for now is up to the CODI guys.
>
> Werner
>
>
>
Re: [core extcdi] is required to create another proposal about windowId?
Posted by Werner Punz <we...@gmail.com>.
Am 11/17/11 7:15 PM, schrieb Leonardo Uribe:
> Hi
>
> In the last days there was some work in these issues:
>
> (EXTCDI-242) improve ClientSideWindowHandler windowId passing via cookie
> (EXTCDI-241) Allow users of the ClientSideWindowHandler to specify if
> it should get applied per Request
> (EXTCDI-240) Enhance ClientSideWindowHandler - remove flickering, etc
>
> Just one question: if the flickering problem was fixed on the current
> solution done on EXTCDI, it is still necessary to create an
> implementation inside myfaces core for windowId? This problem is on my
> list of things to do, so it is better to ask first.
>
> regards,
>
> Leonardo Uribe
>
Good question, I guess we need something for WindowID handling for
jsf2.2 especially given in hindisght of what is planned for 2.2
according to Ed Burns blog but the final answer for now is up to the
CODI guys.
Werner