myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [core extcdi] is required to create another proposal about windowId?
Date Fri, 18 Nov 2011 15:41:35 GMT
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 <jakob.korherr@gmail.com>
> To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg <struberg@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 <struberg@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 <lu4242@gmail.com>
>>>  To: MyFaces Development <dev@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 <gerhard.petracek@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 <werner.punz@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
> 

Mime
View raw message