myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: [core extcdi] is required to create another proposal about windowId?
Date Sun, 20 Nov 2011 22:49:36 GMT
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 <struberg@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 <lu4242@gmail.com>
>> To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg <struberg@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 <struberg@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 <lu4242@gmail.com>
>>>>  To: MyFaces Development <dev@myfaces.apache.org>; Mark Struberg
>> <struberg@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 <struberg@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 <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
>>>>>>
>>>>>
>>>>
>>>
>>
>



-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Mime
View raw message