Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Gerhard Petracek
+1

regards,
gerhard



2014/1/9 Thomas Andraschko andraschko.tho...@gmail.com

 Hi,

 currently the default rendering mode is our windowhandler js/html way.
 Many people don't like it because you always get a loading screen for EACH
 GET request:


 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
 https://issues.apache.org/jira/browse/DELTASPIKE-454

 i readded a URL rendering mode in DS like it was in CODI.
 I know that it doesn't cover all cases but it's likely enough for the most
 users.

 What do you think about making the URL mode as default like it was in CODI
 before?

 Regards,
 Thomas



Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Mark Struberg
The URL rendering mode of CODI is what I intended with LAZY.


LieGrue,
strub





 From: Gerhard Petracek gerhard.petra...@gmail.com
To: dev@deltaspike.apache.org 
Sent: Friday, 10 January 2014, 9:33
Subject: Re: JSF - default ClientWindowRenderMode?
 

+1

regards,
gerhard




2014/1/9 Thomas Andraschko andraschko.tho...@gmail.com

 Hi,

 currently the default rendering mode is our windowhandler js/html way.
 Many people don't like it because you always get a loading screen for EACH
 GET request:


 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
 https://issues.apache.org/jira/browse/DELTASPIKE-454

 i readded a URL rendering mode in DS like it was in CODI.
 I know that it doesn't cover all cases but it's likely enough for the most
 users.

 What do you think about making the URL mode as default like it was in CODI
 before?

 Regards,
 Thomas





Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Thomas Andraschko
As LAZY is currently not used, no documentation available and the javadoc
said something about javascript handling on client side, i thought it
will a different kind of handling in the future.
What should be difference between URL rendering mode and LAZY?



2014/1/10 Mark Struberg strub...@yahoo.de

 The URL rendering mode of CODI is what I intended with LAZY.


 LieGrue,
 strub




 
  From: Gerhard Petracek gerhard.petra...@gmail.com
 To: dev@deltaspike.apache.org
 Sent: Friday, 10 January 2014, 9:33
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 +1
 
 regards,
 gerhard
 
 
 
 
 2014/1/9 Thomas Andraschko andraschko.tho...@gmail.com
 
  Hi,
 
  currently the default rendering mode is our windowhandler js/html way.
  Many people don't like it because you always get a loading screen for
 EACH
  GET request:
 
 
 
 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
  https://issues.apache.org/jira/browse/DELTASPIKE-454
 
  i readded a URL rendering mode in DS like it was in CODI.
  I know that it doesn't cover all cases but it's likely enough for the
 most
  users.
 
  What do you think about making the URL mode as default like it was in
 CODI
  before?
 
  Regards,
  Thomas
 
 
 
 



Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Mark Struberg


Hi Thomas!

Well, it's just a different name ;)

The default handling in CODI is lazy windowId dropping if you do not use the 
ClientSideWindowHandler.
Means a request runs through to the target bean and renders the page. And the 
windowId only gets checked/reset when the page gets loaded by the browser and 
the javascript _lazily_ detects that we are on the wrong browser tab (windowId 
!= window.name). 


Transporting the windowId via URL is only a small necessity actually ;)

ds:windowId should already contain all the JavaScript needed for the lazy 
dropping.


LieGrue,
strub






 From: Thomas Andraschko andraschko.tho...@gmail.com
To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de 
Sent: Friday, 10 January 2014, 10:50
Subject: Re: JSF - default ClientWindowRenderMode?
 


As LAZY is currently not used, no documentation available and the javadoc said 
something about javascript handling on client side, i thought it will a 
different kind of handling in the future.
What should be difference between URL rendering mode and LAZY?






2014/1/10 Mark Struberg strub...@yahoo.de

The URL rendering mode of CODI is what I intended with LAZY.


LieGrue,
strub





 From: Gerhard Petracek gerhard.petra...@gmail.com
To: dev@deltaspike.apache.org
Sent: Friday, 10 January 2014, 9:33
Subject: Re: JSF - default ClientWindowRenderMode?



+1

regards,
gerhard




2014/1/9 Thomas Andraschko andraschko.tho...@gmail.com

 Hi,

 currently the default rendering mode is our windowhandler js/html way.
 Many people don't like it because you always get a loading screen for EACH
 GET request:


 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
 https://issues.apache.org/jira/browse/DELTASPIKE-454

 i readded a URL rendering mode in DS like it was in CODI.
 I know that it doesn't cover all cases but it's likely enough for the most
 users.

 What do you think about making the URL mode as default like it was in CODI
 before?

 Regards,
 Thomas









Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Thomas Andraschko
Hi Mark,

i think the whole stuff needs a little bit more discussing.

I would like now to list all window modes that we actually know:

CODI

- WIndowContextIdHolderComponent will automatically be added to the
component tree for extracting the windowId in a postback
- All 3 modes can use the WIndowContextIdHolderComponent as fallback for
getting the windowId in a postback

1) DefaultWindowHandler
   - Always appends the windowId to the URL and always gets the windowId
from the URL
   - No JS checks etc.
   - opening a link in a new tab will not detect a new window / same window
will be reused

2) ClientSideWindowHandler
   - Stream our windowhandler
   - windowhandler.html checks the window.name
   - if valid - set cookie and redirect to the same page
   - if invalid - remove windowId url param and redirect to the same
page
   - overwrites all click events to capturing a screenshot which will
be displayed for further get requests?
   - Also appends the windowId to the URL?
   - The only mode which supports all edge cases

3) ServerSideWindowHandler
   - Stored the windowId via flash-scope on redirect
   - Also appends the windowId to the URL?
   - opening a link in a new tab will not detect a new window / same window
will be reused



DeltaSpike:

- WindowIdComponent must be added manually

1) CLIENT_WINDOW:
   - same as CODIs ClientSideWindowHandler
2) LAZY
   - new mix between DefaultWindowHandler and ClientSideWindowHandler?
   - renders the URL param but validates the windowID via windowhandler.js,
which will be loaded when the ds:windowId will be added in the view

3) URL (new)
   - same as CODIs DefaultWindowHandler

4) Delegated
   - take use of JSF 2.2

Is this right? Please correct me! We can take this as base for the
documention later.

Regards,
Thomas










2014/1/10 Mark Struberg strub...@yahoo.de



 Hi Thomas!

 Well, it's just a different name ;)

 The default handling in CODI is lazy windowId dropping if you do not use
 the ClientSideWindowHandler.
 Means a request runs through to the target bean and renders the page. And
 the windowId only gets checked/reset when the page gets loaded by the
 browser and the javascript _lazily_ detects that we are on the wrong
 browser tab (windowId != window.name).


 Transporting the windowId via URL is only a small necessity actually ;)

 ds:windowId should already contain all the JavaScript needed for the
 lazy dropping.


 LieGrue,
 strub





 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 10:50
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 As LAZY is currently not used, no documentation available and the javadoc
 said something about javascript handling on client side, i thought it
 will a different kind of handling in the future.
 What should be difference between URL rendering mode and LAZY?
 
 
 
 
 
 
 2014/1/10 Mark Struberg strub...@yahoo.de
 
 The URL rendering mode of CODI is what I intended with LAZY.
 
 
 LieGrue,
 strub
 
 
 
 
 
  From: Gerhard Petracek gerhard.petra...@gmail.com
 To: dev@deltaspike.apache.org
 Sent: Friday, 10 January 2014, 9:33
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 +1
 
 regards,
 gerhard
 
 
 
 
 2014/1/9 Thomas Andraschko andraschko.tho...@gmail.com
 
  Hi,
 
  currently the default rendering mode is our windowhandler js/html way.
  Many people don't like it because you always get a loading screen for
 EACH
  GET request:
 
 
 
 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
  https://issues.apache.org/jira/browse/DELTASPIKE-454
 
  i readded a URL rendering mode in DS like it was in CODI.
  I know that it doesn't cover all cases but it's likely enough for the
 most
  users.
 
  What do you think about making the URL mode as default like it was in
 CODI
  before?
 
  Regards,
  Thomas
 
 
 
 
 
 
 



Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Thomas Andraschko
Addition to the windowhandler:
It will also add windowId as hidden input for postback detection, right?
This will not work with e.g. PrimeFaces' partial submit mode.
So the URL param will be used as fallback, right?


2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com

 Hi Mark,

 i think the whole stuff needs a little bit more discussing.

 I would like now to list all window modes that we actually know:

 CODI
 
 - WIndowContextIdHolderComponent will automatically be added to the
 component tree for extracting the windowId in a postback
 - All 3 modes can use the WIndowContextIdHolderComponent as fallback for
 getting the windowId in a postback

 1) DefaultWindowHandler
- Always appends the windowId to the URL and always gets the windowId
 from the URL
- No JS checks etc.
- opening a link in a new tab will not detect a new window / same
 window will be reused

 2) ClientSideWindowHandler
- Stream our windowhandler
- windowhandler.html checks the window.name
- if valid - set cookie and redirect to the same page
- if invalid - remove windowId url param and redirect to the same
 page
- overwrites all click events to capturing a screenshot which will
 be displayed for further get requests?
- Also appends the windowId to the URL?
- The only mode which supports all edge cases

 3) ServerSideWindowHandler
- Stored the windowId via flash-scope on redirect
- Also appends the windowId to the URL?
- opening a link in a new tab will not detect a new window / same
 window will be reused



 DeltaSpike:
 
 - WindowIdComponent must be added manually

 1) CLIENT_WINDOW:
- same as CODIs ClientSideWindowHandler
 2) LAZY
- new mix between DefaultWindowHandler and ClientSideWindowHandler?
- renders the URL param but validates the windowID via
 windowhandler.js, which will be loaded when the ds:windowId will be added
 in the view

 3) URL (new)
- same as CODIs DefaultWindowHandler

 4) Delegated
- take use of JSF 2.2

 Is this right? Please correct me! We can take this as base for the
 documention later.

 Regards,
 Thomas










 2014/1/10 Mark Struberg strub...@yahoo.de



 Hi Thomas!

 Well, it's just a different name ;)

 The default handling in CODI is lazy windowId dropping if you do not use
 the ClientSideWindowHandler.
 Means a request runs through to the target bean and renders the page. And
 the windowId only gets checked/reset when the page gets loaded by the
 browser and the javascript _lazily_ detects that we are on the wrong
 browser tab (windowId != window.name).


 Transporting the windowId via URL is only a small necessity actually ;)

 ds:windowId should already contain all the JavaScript needed for the
 lazy dropping.


 LieGrue,
 strub





 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 10:50
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 As LAZY is currently not used, no documentation available and the
 javadoc said something about javascript handling on client side, i
 thought it will a different kind of handling in the future.
 What should be difference between URL rendering mode and LAZY?
 
 
 
 
 
 
 2014/1/10 Mark Struberg strub...@yahoo.de
 
 The URL rendering mode of CODI is what I intended with LAZY.
 
 
 LieGrue,
 strub
 
 
 
 
 
  From: Gerhard Petracek gerhard.petra...@gmail.com
 To: dev@deltaspike.apache.org
 Sent: Friday, 10 January 2014, 9:33
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 +1
 
 regards,
 gerhard
 
 
 
 
 2014/1/9 Thomas Andraschko andraschko.tho...@gmail.com
 
  Hi,
 
  currently the default rendering mode is our windowhandler js/html
 way.
  Many people don't like it because you always get a loading screen
 for EACH
  GET request:
 
 
 
 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
  https://issues.apache.org/jira/browse/DELTASPIKE-454
 
  i readded a URL rendering mode in DS like it was in CODI.
  I know that it doesn't cover all cases but it's likely enough for
 the most
  users.
 
  What do you think about making the URL mode as default like it was
 in CODI
  before?
 
  Regards,
  Thomas
 
 
 
 
 
 
 





Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Thomas Andraschko
Addition to DeltaSpike:
The windowIdComponent will be just used to render via JS the current valid
windowId.


2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com

 Addition to the windowhandler:
 It will also add windowId as hidden input for postback detection, right?
 This will not work with e.g. PrimeFaces' partial submit mode.
 So the URL param will be used as fallback, right?


 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com

 Hi Mark,

 i think the whole stuff needs a little bit more discussing.

 I would like now to list all window modes that we actually know:

 CODI
 
 - WIndowContextIdHolderComponent will automatically be added to the
 component tree for extracting the windowId in a postback
 - All 3 modes can use the WIndowContextIdHolderComponent as fallback for
 getting the windowId in a postback

 1) DefaultWindowHandler
- Always appends the windowId to the URL and always gets the windowId
 from the URL
- No JS checks etc.
- opening a link in a new tab will not detect a new window / same
 window will be reused

 2) ClientSideWindowHandler
- Stream our windowhandler
- windowhandler.html checks the window.name
- if valid - set cookie and redirect to the same page
- if invalid - remove windowId url param and redirect to the same
 page
- overwrites all click events to capturing a screenshot which will
 be displayed for further get requests?
- Also appends the windowId to the URL?
- The only mode which supports all edge cases

 3) ServerSideWindowHandler
- Stored the windowId via flash-scope on redirect
- Also appends the windowId to the URL?
- opening a link in a new tab will not detect a new window / same
 window will be reused



 DeltaSpike:
 
 - WindowIdComponent must be added manually

 1) CLIENT_WINDOW:
- same as CODIs ClientSideWindowHandler
 2) LAZY
- new mix between DefaultWindowHandler and ClientSideWindowHandler?
- renders the URL param but validates the windowID via
 windowhandler.js, which will be loaded when the ds:windowId will be added
 in the view

 3) URL (new)
- same as CODIs DefaultWindowHandler

 4) Delegated
- take use of JSF 2.2

 Is this right? Please correct me! We can take this as base for the
 documention later.

 Regards,
 Thomas










 2014/1/10 Mark Struberg strub...@yahoo.de



 Hi Thomas!

 Well, it's just a different name ;)

 The default handling in CODI is lazy windowId dropping if you do not use
 the ClientSideWindowHandler.
 Means a request runs through to the target bean and renders the page.
 And the windowId only gets checked/reset when the page gets loaded by the
 browser and the javascript _lazily_ detects that we are on the wrong
 browser tab (windowId != window.name).


 Transporting the windowId via URL is only a small necessity actually ;)

 ds:windowId should already contain all the JavaScript needed for the
 lazy dropping.


 LieGrue,
 strub





 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 10:50
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 As LAZY is currently not used, no documentation available and the
 javadoc said something about javascript handling on client side, i
 thought it will a different kind of handling in the future.
 What should be difference between URL rendering mode and LAZY?
 
 
 
 
 
 
 2014/1/10 Mark Struberg strub...@yahoo.de
 
 The URL rendering mode of CODI is what I intended with LAZY.
 
 
 LieGrue,
 strub
 
 
 
 
 
  From: Gerhard Petracek gerhard.petra...@gmail.com
 To: dev@deltaspike.apache.org
 Sent: Friday, 10 January 2014, 9:33
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 +1
 
 regards,
 gerhard
 
 
 
 
 2014/1/9 Thomas Andraschko andraschko.tho...@gmail.com
 
  Hi,
 
  currently the default rendering mode is our windowhandler js/html
 way.
  Many people don't like it because you always get a loading screen
 for EACH
  GET request:
 
 
 
 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
  https://issues.apache.org/jira/browse/DELTASPIKE-454
 
  i readded a URL rendering mode in DS like it was in CODI.
  I know that it doesn't cover all cases but it's likely enough for
 the most
  users.
 
  What do you think about making the URL mode as default like it was
 in CODI
  before?
 
  Regards,
  Thomas
 
 
 
 
 
 
 






Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Mark Struberg
right.

Basically you have to distinguish the two sides of the story.

a.) how does the browser handle the windowId
b.) how does any servlet part detect the windodwId and how to detect that it is 
missing (and should be there)

The windowId is added as root element to the view tree. I know that this did 
not work with the 'old' PrimeFaces proprietary ajax handling. But i was under 
the impression that this was long time fixed since then when Cagatay switched 
to standard jsf.js AJAX functions. Or is this still not working?

The point is that jsf.js always has to update the view root as it also needs to 
update the view key, right?

LieGrue,
strub





 From: Thomas Andraschko andraschko.tho...@gmail.com
To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de 
Sent: Friday, 10 January 2014, 11:38
Subject: Re: JSF - default ClientWindowRenderMode?
 


Addition to the windowhandler:
It will also add windowId as hidden input for postback detection, right?
This will not work with e.g. PrimeFaces' partial submit mode.
So the URL param will be used as fallback, right?




2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com

Hi Mark,

i think the whole stuff needs a little bit more discussing.


I would like now to list all window modes that we actually know:


CODI

- WIndowContextIdHolderComponent will automatically be added to the component 
tree for extracting the windowId in a postback
- All 3 modes can use the WIndowContextIdHolderComponent as fallback for 
getting the windowId in a postback


1) DefaultWindowHandler

   - Always appends the windowId to the URL and always gets the windowId from 
the URL

   - No JS checks etc.

   - opening a link in a new tab will not detect a new window / same window 
will be reused



2) ClientSideWindowHandler

   - Stream our windowhandler 

   - windowhandler.html checks the window.name

   - if valid - set cookie and redirect to the same page

   - if invalid - remove windowId url param and redirect to the same page

   - overwrites all click events to capturing a screenshot which will be 
displayed for further get requests?

   - Also appends the windowId to the URL?

   - The only mode which supports all edge cases


3) ServerSideWindowHandler

   - Stored the windowId via flash-scope on redirect

   - Also appends the windowId to the URL?
   - opening a link in a new tab will not detect a new window / same window 
will be reused






DeltaSpike:


- WindowIdComponent must be added manually



1) CLIENT_WINDOW:
   - same as CODIs ClientSideWindowHandler

2) LAZY
   - new mix between DefaultWindowHandler and ClientSideWindowHandler?

   - renders the URL param but validates the windowID via windowhandler.js, 
which will be loaded when the ds:windowId will be added in the view



3) URL (new)

   - same as CODIs DefaultWindowHandler


4) Delegated

   - take use of JSF 2.2


Is this right? Please correct me! We can take this as base for the 
documention later.


Regards,
Thomas


















2014/1/10 Mark Struberg strub...@yahoo.de



Hi Thomas!

Well, it's just a different name ;)

The default handling in CODI is lazy windowId dropping if you do not use the 
ClientSideWindowHandler.
Means a request runs through to the target bean and renders the page. And 
the windowId only gets checked/reset when the page gets loaded by the 
browser and the javascript _lazily_ detects that we are on the wrong browser 
tab (windowId != window.name).


Transporting the windowId via URL is only a small necessity actually ;)

ds:windowId should already contain all the JavaScript needed for the lazy 
dropping.


LieGrue,
strub






 From: Thomas Andraschko andraschko.tho...@gmail.com
To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
Sent: Friday, 10 January 2014, 10:50

Subject: Re: JSF - default ClientWindowRenderMode?



As LAZY is currently not used, no documentation available and the javadoc 
said something about javascript handling on client side, i thought it 
will a different kind of handling in the future.
What should be difference between URL rendering mode and LAZY?






2014/1/10 Mark Struberg strub...@yahoo.de

The URL rendering mode of CODI is what I intended with LAZY.


LieGrue,
strub





 From: Gerhard Petracek gerhard.petra...@gmail.com
To: dev@deltaspike.apache.org
Sent: Friday, 10 January 2014, 9:33
Subject: Re: JSF - default ClientWindowRenderMode?



+1

regards,
gerhard




2014/1/9 Thomas Andraschko andraschko.tho...@gmail.com

 Hi,

 currently the default rendering mode is our windowhandler js/html way.
 Many people don't like it because you always get a loading screen for 
 EACH
 GET request:


 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
 https://issues.apache.org/jira/browse/DELTASPIKE-454

 i readded a URL rendering mode in DS like

Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Thomas Andraschko
Ok! So keeping the new URL mode, which is indentical to the deafult CODI
mode, makes sense for me.

I will open another thread for the details here and some ideas about
refactoring from my side.

What do think about the default mode Mark? Should it be URL like its in
CODI?









2014/1/10 Mark Struberg strub...@yahoo.de

 right.

 Basically you have to distinguish the two sides of the story.

 a.) how does the browser handle the windowId
 b.) how does any servlet part detect the windodwId and how to detect that
 it is missing (and should be there)

 The windowId is added as root element to the view tree. I know that this
 did not work with the 'old' PrimeFaces proprietary ajax handling. But i was
 under the impression that this was long time fixed since then when Cagatay
 switched to standard jsf.js AJAX functions. Or is this still not working?

 The point is that jsf.js always has to update the view root as it also
 needs to update the view key, right?

 LieGrue,
 strub




 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 11:38
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 Addition to the windowhandler:
 It will also add windowId as hidden input for postback detection, right?
 This will not work with e.g. PrimeFaces' partial submit mode.
 So the URL param will be used as fallback, right?
 
 
 
 
 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
 
 Hi Mark,
 
 i think the whole stuff needs a little bit more discussing.
 
 
 I would like now to list all window modes that we actually know:
 
 
 CODI
 
 - WIndowContextIdHolderComponent will automatically be added to the
 component tree for extracting the windowId in a postback
 - All 3 modes can use the WIndowContextIdHolderComponent as fallback for
 getting the windowId in a postback
 
 
 1) DefaultWindowHandler
 
- Always appends the windowId to the URL and always gets the windowId
 from the URL
 
- No JS checks etc.
 
- opening a link in a new tab will not detect a new window / same
 window will be reused
 
 
 
 2) ClientSideWindowHandler
 
- Stream our windowhandler
 
- windowhandler.html checks the window.name
 
- if valid - set cookie and redirect to the same page
 
- if invalid - remove windowId url param and redirect to the
 same page
 
- overwrites all click events to capturing a screenshot which
 will be displayed for further get requests?
 
- Also appends the windowId to the URL?
 
- The only mode which supports all edge cases
 
 
 3) ServerSideWindowHandler
 
- Stored the windowId via flash-scope on redirect
 
- Also appends the windowId to the URL?
- opening a link in a new tab will not detect a new window / same
 window will be reused
 
 
 
 
 
 
 DeltaSpike:
 
 
 - WindowIdComponent must be added manually
 
 
 
 1) CLIENT_WINDOW:
- same as CODIs ClientSideWindowHandler
 
 2) LAZY
- new mix between DefaultWindowHandler and ClientSideWindowHandler?
 
- renders the URL param but validates the windowID via
 windowhandler.js, which will be loaded when the ds:windowId will be added
 in the view
 
 
 
 3) URL (new)
 
- same as CODIs DefaultWindowHandler
 
 
 4) Delegated
 
- take use of JSF 2.2
 
 
 Is this right? Please correct me! We can take this as base for the
 documention later.
 
 
 Regards,
 Thomas
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 2014/1/10 Mark Struberg strub...@yahoo.de
 
 
 
 Hi Thomas!
 
 Well, it's just a different name ;)
 
 The default handling in CODI is lazy windowId dropping if you do not
 use the ClientSideWindowHandler.
 Means a request runs through to the target bean and renders the page.
 And the windowId only gets checked/reset when the page gets loaded by the
 browser and the javascript _lazily_ detects that we are on the wrong
 browser tab (windowId != window.name).
 
 
 Transporting the windowId via URL is only a small necessity actually ;)
 
 ds:windowId should already contain all the JavaScript needed for the
 lazy dropping.
 
 
 LieGrue,
 strub
 
 
 
 
 
 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 10:50
 
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 As LAZY is currently not used, no documentation available and the
 javadoc said something about javascript handling on client side, i
 thought it will a different kind of handling in the future.
 What should be difference between URL rendering mode and LAZY?
 
 
 
 
 
 
 2014/1/10 Mark Struberg strub...@yahoo.de
 
 The URL rendering mode of CODI is what I intended with LAZY.
 
 
 LieGrue,
 strub
 
 
 
 
 
  From: Gerhard Petracek gerhard.petra...@gmail.com
 To: dev@deltaspike.apache.org
 Sent: Friday, 10 January

Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Thomas Andraschko
Ok would be fine for me, too!
The script for the LAZY mode will just do:
- if window.name == undefined - window.name == windowId
- if window.name != undefined  window.name != windowId - redirect with
removed windowId url param




2014/1/10 Mark Struberg strub...@yahoo.de



 I'm fine with making the 'URL' mode the default. I still like the name
 'LAZY' better though ;)

 Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in
 some cases!
 The name 'LAZY' just makes it more clear that the
 wrong-browser-tab-detection is only done lazily and the initial request
 might trash beans...


 LieGrue,
 strub


 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 13:43
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 Ok! So keeping the new URL mode, which is indentical to the deafult CODI
 mode, makes sense for me.
 
 I will open another thread for the details here and some ideas about
 refactoring from my side.
 
 What do think about the default mode Mark? Should it be URL like its in
 CODI?
 
 
 
 
 
 
 
 
 
 
 2014/1/10 Mark Struberg strub...@yahoo.de
 
  right.
 
  Basically you have to distinguish the two sides of the story.
 
  a.) how does the browser handle the windowId
  b.) how does any servlet part detect the windodwId and how to detect
 that
  it is missing (and should be there)
 
  The windowId is added as root element to the view tree. I know that this
  did not work with the 'old' PrimeFaces proprietary ajax handling. But i
 was
  under the impression that this was long time fixed since then when
 Cagatay
  switched to standard jsf.js AJAX functions. Or is this still not
 working?
 
  The point is that jsf.js always has to update the view root as it also
  needs to update the view key, right?
 
  LieGrue,
  strub
 
 
 
 
  
   From: Thomas Andraschko andraschko.tho...@gmail.com
  To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
  Sent: Friday, 10 January 2014, 11:38
  Subject: Re: JSF - default ClientWindowRenderMode?
  
  
  
  Addition to the windowhandler:
  It will also add windowId as hidden input for postback detection,
 right?
  This will not work with e.g. PrimeFaces' partial submit mode.
  So the URL param will be used as fallback, right?
  
  
  
  
  2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
  
  Hi Mark,
  
  i think the whole stuff needs a little bit more discussing.
  
  
  I would like now to list all window modes that we actually know:
  
  
  CODI
  
  - WIndowContextIdHolderComponent will automatically be added to the
  component tree for extracting the windowId in a postback
  - All 3 modes can use the WIndowContextIdHolderComponent as fallback
 for
  getting the windowId in a postback
  
  
  1) DefaultWindowHandler
  
 - Always appends the windowId to the URL and always gets the
 windowId
  from the URL
  
 - No JS checks etc.
  
 - opening a link in a new tab will not detect a new window / same
  window will be reused
  
  
  
  2) ClientSideWindowHandler
  
 - Stream our windowhandler
  
 - windowhandler.html checks the window.name
  
 - if valid - set cookie and redirect to the same page
  
 - if invalid - remove windowId url param and redirect to the
  same page
  
 - overwrites all click events to capturing a screenshot which
  will be displayed for further get requests?
  
 - Also appends the windowId to the URL?
  
 - The only mode which supports all edge cases
  
  
  3) ServerSideWindowHandler
  
 - Stored the windowId via flash-scope on redirect
  
 - Also appends the windowId to the URL?
 - opening a link in a new tab will not detect a new window / same
  window will be reused
  
  
  
  
  
  
  DeltaSpike:
  
  
  - WindowIdComponent must be added manually
  
  
  
  1) CLIENT_WINDOW:
 - same as CODIs ClientSideWindowHandler
  
  2) LAZY
 - new mix between DefaultWindowHandler and ClientSideWindowHandler?
  
 - renders the URL param but validates the windowID via
  windowhandler.js, which will be loaded when the ds:windowId will be
 added
  in the view
  
  
  
  3) URL (new)
  
 - same as CODIs DefaultWindowHandler
  
  
  4) Delegated
  
 - take use of JSF 2.2
  
  
  Is this right? Please correct me! We can take this as base for the
  documention later.
  
  
  Regards,
  Thomas
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  2014/1/10 Mark Struberg strub...@yahoo.de
  
  
  
  Hi Thomas!
  
  Well, it's just a different name ;)
  
  The default handling in CODI is lazy windowId dropping if you do not
  use the ClientSideWindowHandler.
  Means a request runs through to the target bean and renders the page.
  And the windowId only gets checked/reset when the page gets loaded by
 the
  browser and the javascript _lazily_

Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Mark Struberg


It's a bit more complicated.

In case of any mismatch (regardless if window.name is empty or just different 
from the windowId url parameter) you need to trigger a more complex handling to 
properly set the window.name.

Otherwise one could just open the same bookmark URL with the windowId=123 
parameter in multiple browser tabs and you would again share the state between 
them.

Actually the windowhandler.js script should contain all the necessary handling 
code already.

LieGrue,
strub






 From: Thomas Andraschko andraschko.tho...@gmail.com
To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de 
Sent: Friday, 10 January 2014, 13:58
Subject: Re: JSF - default ClientWindowRenderMode?
 


Ok would be fine for me, too!
The script for the LAZY mode will just do:
- if window.name == undefined - window.name == windowId
- if window.name != undefined  window.name != windowId - redirect with 
removed windowId url param






2014/1/10 Mark Struberg strub...@yahoo.de



I'm fine with making the 'URL' mode the default. I still like the name 'LAZY' 
better though ;)

Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in some 
cases!
The name 'LAZY' just makes it more clear that the wrong-browser-tab-detection 
is only done lazily and the initial request might trash beans...



LieGrue,
strub



 From: Thomas Andraschko andraschko.tho...@gmail.com
To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
Sent: Friday, 10 January 2014, 13:43

Subject: Re: JSF - default ClientWindowRenderMode?


Ok! So keeping the new URL mode, which is indentical to the deafult CODI
mode, makes sense for me.

I will open another thread for the details here and some ideas about
refactoring from my side.

What do think about the default mode Mark? Should it be URL like its in
CODI?










2014/1/10 Mark Struberg strub...@yahoo.de

 right.

 Basically you have to distinguish the two sides of the story.

 a.) how does the browser handle the windowId
 b.) how does any servlet part detect the windodwId and how to detect that
 it is missing (and should be there)

 The windowId is added as root element to the view tree. I know that this
 did not work with the 'old' PrimeFaces proprietary ajax handling. But i was
 under the impression that this was long time fixed since then when Cagatay
 switched to standard jsf.js AJAX functions. Or is this still not working?

 The point is that jsf.js always has to update the view root as it also
 needs to update the view key, right?

 LieGrue,
 strub




 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 11:38
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 Addition to the windowhandler:
 It will also add windowId as hidden input for postback detection, right?
 This will not work with e.g. PrimeFaces' partial submit mode.
 So the URL param will be used as fallback, right?
 
 
 
 
 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
 
 Hi Mark,
 
 i think the whole stuff needs a little bit more discussing.
 
 
 I would like now to list all window modes that we actually know:
 
 
 CODI
 
 - WIndowContextIdHolderComponent will automatically be added to the
 component tree for extracting the windowId in a postback
 - All 3 modes can use the WIndowContextIdHolderComponent as fallback for
 getting the windowId in a postback
 
 
 1) DefaultWindowHandler
 
    - Always appends the windowId to the URL and always gets the windowId
 from the URL
 
    - No JS checks etc.
 
    - opening a link in a new tab will not detect a new window / same
 window will be reused
 
 
 
 2) ClientSideWindowHandler
 
    - Stream our windowhandler
 
    - windowhandler.html checks the window.name
 
        - if valid - set cookie and redirect to the same page
 
        - if invalid - remove windowId url param and redirect to the
 same page
 
        - overwrites all click events to capturing a screenshot which
 will be displayed for further get requests?
 
    - Also appends the windowId to the URL?
 
    - The only mode which supports all edge cases
 
 
 3) ServerSideWindowHandler
 
    - Stored the windowId via flash-scope on redirect
 
    - Also appends the windowId to the URL?
    - opening a link in a new tab will not detect a new window / same
 window will be reused
 
 
 
 
 
 
 DeltaSpike:
 
 
 - WindowIdComponent must be added manually
 
 
 
 1) CLIENT_WINDOW:
    - same as CODIs ClientSideWindowHandler
 
 2) LAZY
    - new mix between DefaultWindowHandler and ClientSideWindowHandler?
 
    - renders the URL param but validates the windowID via
 windowhandler.js, which will be loaded when the ds:windowId will be added
 in the view
 
 
 
 3) URL (new)
 
    - same as CODIs DefaultWindowHandler
 
 
 4) Delegated
 
    - take use of JSF 2.2

Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Thomas Andraschko
2014/1/10 Mark Struberg strub...@yahoo.de

 Otherwise one could just open the same bookmark URL with the windowId=123
 parameter in multiple browser tabs and you would again share the state
 between them.


Thats true but as far as i understand, we can't avoid such situations
without streaming the windowhandler etc.

Maybe you can explain LAZY a little bit more + some cases.


2014/1/10 Mark Struberg strub...@yahoo.de



 It's a bit more complicated.

 In case of any mismatch (regardless if window.name is empty or just
 different from the windowId url parameter) you need to trigger a more
 complex handling to properly set the window.name.

 Otherwise one could just open the same bookmark URL with the windowId=123
 parameter in multiple browser tabs and you would again share the state
 between them.

 Actually the windowhandler.js script should contain all the necessary
 handling code already.

 LieGrue,
 strub





 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 13:58
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 Ok would be fine for me, too!
 The script for the LAZY mode will just do:
 - if window.name == undefined - window.name == windowId
 - if window.name != undefined  window.name != windowId - redirect
 with removed windowId url param
 
 
 
 
 
 
 2014/1/10 Mark Struberg strub...@yahoo.de
 
 
 
 I'm fine with making the 'URL' mode the default. I still like the name
 'LAZY' better though ;)
 
 Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in
 some cases!
 The name 'LAZY' just makes it more clear that the
 wrong-browser-tab-detection is only done lazily and the initial request
 might trash beans...
 
 
 
 LieGrue,
 strub
 
 
 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 13:43
 
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 Ok! So keeping the new URL mode, which is indentical to the deafult CODI
 mode, makes sense for me.
 
 I will open another thread for the details here and some ideas about
 refactoring from my side.
 
 What do think about the default mode Mark? Should it be URL like its in
 CODI?
 
 
 
 
 
 
 
 
 
 
 2014/1/10 Mark Struberg strub...@yahoo.de
 
  right.
 
  Basically you have to distinguish the two sides of the story.
 
  a.) how does the browser handle the windowId
  b.) how does any servlet part detect the windodwId and how to detect
 that
  it is missing (and should be there)
 
  The windowId is added as root element to the view tree. I know that
 this
  did not work with the 'old' PrimeFaces proprietary ajax handling. But
 i was
  under the impression that this was long time fixed since then when
 Cagatay
  switched to standard jsf.js AJAX functions. Or is this still not
 working?
 
  The point is that jsf.js always has to update the view root as it also
  needs to update the view key, right?
 
  LieGrue,
  strub
 
 
 
 
  
   From: Thomas Andraschko andraschko.tho...@gmail.com
  To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
  Sent: Friday, 10 January 2014, 11:38
  Subject: Re: JSF - default ClientWindowRenderMode?
  
  
  
  Addition to the windowhandler:
  It will also add windowId as hidden input for postback detection,
 right?
  This will not work with e.g. PrimeFaces' partial submit mode.
  So the URL param will be used as fallback, right?
  
  
  
  
  2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
  
  Hi Mark,
  
  i think the whole stuff needs a little bit more discussing.
  
  
  I would like now to list all window modes that we actually know:
  
  
  CODI
  
  - WIndowContextIdHolderComponent will automatically be added to the
  component tree for extracting the windowId in a postback
  - All 3 modes can use the WIndowContextIdHolderComponent as
 fallback for
  getting the windowId in a postback
  
  
  1) DefaultWindowHandler
  
 - Always appends the windowId to the URL and always gets the
 windowId
  from the URL
  
 - No JS checks etc.
  
 - opening a link in a new tab will not detect a new window / same
  window will be reused
  
  
  
  2) ClientSideWindowHandler
  
 - Stream our windowhandler
  
 - windowhandler.html checks the window.name
  
 - if valid - set cookie and redirect to the same page
  
 - if invalid - remove windowId url param and redirect to the
  same page
  
 - overwrites all click events to capturing a screenshot which
  will be displayed for further get requests?
  
 - Also appends the windowId to the URL?
  
 - The only mode which supports all edge cases
  
  
  3) ServerSideWindowHandler
  
 - Stored the windowId via flash-scope on redirect
  
 - Also appends the windowId to the URL

Re: JSF - default ClientWindowRenderMode?

2014-01-10 Thread Mark Struberg
we can - if we detect such a case we generate a fresh windowId + javascript 
code which forces setting the window.name.
Same applies atm if the server got hit by a GET without a windowId parameter. 
In this case we did an 'initial redirect' in CODI.

So even the LAZY approach could result in having multiple GET if the windowId 
does not fit. The difference is that you do not get it for _every_ GET, but the 
downside is that you might trash bean state on the initial request.


LieGrue,
strub





 From: Thomas Andraschko andraschko.tho...@gmail.com
To: Mark Struberg strub...@yahoo.de 
Cc: dev@deltaspike.apache.org dev@deltaspike.apache.org 
Sent: Friday, 10 January 2014, 14:18
Subject: Re: JSF - default ClientWindowRenderMode?
 


2014/1/10 Mark Struberg strub...@yahoo.de

Otherwise one could just open the same bookmark URL with the 
windowId=123 parameter in multiple browser tabs and you would again share the 
state between them.

Thats true but as far as i understand, we can't avoid such situations without 
streaming the windowhandler etc.


Maybe you can explain LAZY a little bit more + some cases.



2014/1/10 Mark Struberg strub...@yahoo.de



It's a bit more complicated.

In case of any mismatch (regardless if window.name is empty or just different 
from the windowId url parameter) you need to trigger a more complex handling 
to properly set the window.name.

Otherwise one could just open the same bookmark URL with the windowId=123 
parameter in multiple browser tabs and you would again share the state 
between them.

Actually the windowhandler.js script should contain all the necessary 
handling code already.


LieGrue,
strub






 From: Thomas Andraschko andraschko.tho...@gmail.com
To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
Sent: Friday, 10 January 2014, 13:58

Subject: Re: JSF - default ClientWindowRenderMode?



Ok would be fine for me, too!
The script for the LAZY mode will just do:
- if window.name == undefined - window.name == windowId
- if window.name != undefined  window.name != windowId - redirect with 
removed windowId url param






2014/1/10 Mark Struberg strub...@yahoo.de



I'm fine with making the 'URL' mode the default. I still like the name 
'LAZY' better though ;)

Even the CLIENT_WINDOW mode will add a windowId parameter to the URL in 
some cases!
The name 'LAZY' just makes it more clear that the 
wrong-browser-tab-detection is only done lazily and the initial request 
might trash beans...



LieGrue,
strub



 From: Thomas Andraschko andraschko.tho...@gmail.com
To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
Sent: Friday, 10 January 2014, 13:43

Subject: Re: JSF - default ClientWindowRenderMode?


Ok! So keeping the new URL mode, which is indentical to the deafult CODI
mode, makes sense for me.

I will open another thread for the details here and some ideas about
refactoring from my side.

What do think about the default mode Mark? Should it be URL like its in
CODI?










2014/1/10 Mark Struberg strub...@yahoo.de

 right.

 Basically you have to distinguish the two sides of the story.

 a.) how does the browser handle the windowId
 b.) how does any servlet part detect the windodwId and how to detect that
 it is missing (and should be there)

 The windowId is added as root element to the view tree. I know that this
 did not work with the 'old' PrimeFaces proprietary ajax handling. But i 
 was
 under the impression that this was long time fixed since then when 
 Cagatay
 switched to standard jsf.js AJAX functions. Or is this still not working?

 The point is that jsf.js always has to update the view root as it also
 needs to update the view key, right?

 LieGrue,
 strub




 
  From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org; Mark Struberg strub...@yahoo.de
 Sent: Friday, 10 January 2014, 11:38
 Subject: Re: JSF - default ClientWindowRenderMode?
 
 
 
 Addition to the windowhandler:
 It will also add windowId as hidden input for postback detection, right?
 This will not work with e.g. PrimeFaces' partial submit mode.
 So the URL param will be used as fallback, right?
 
 
 
 
 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
 
 Hi Mark,
 
 i think the whole stuff needs a little bit more discussing.
 
 
 I would like now to list all window modes that we actually know:
 
 
 CODI
 
 - WIndowContextIdHolderComponent will automatically be added to the
 component tree for extracting the windowId in a postback
 - All 3 modes can use the WIndowContextIdHolderComponent as fallback 
 for
 getting the windowId in a postback
 
 
 1) DefaultWindowHandler
 
    - Always appends the windowId to the URL and always gets the 
 windowId
 from the URL
 
    - No JS checks etc.
 
    - opening a link in a new tab will not detect a new window / same
 window will be reused

Re: JSF - default ClientWindowRenderMode?

2014-01-09 Thread Karl Kildén
If I ever were to post a meme to this mail list it would probably be:

If my application could have just one of dsRid and windowId and no loading
splash I would be so happy

cheers


On 9 January 2014 22:52, Thomas Andraschko andraschko.tho...@gmail.comwrote:

 Hi,

 currently the default rendering mode is our windowhandler js/html way.
 Many people don't like it because you always get a loading screen for EACH
 GET request:


 http://stackoverflow.com/questions/18090603/how-to-disable-loading-screen-of-deltaspike
 https://issues.apache.org/jira/browse/DELTASPIKE-454

 i readded a URL rendering mode in DS like it was in CODI.
 I know that it doesn't cover all cases but it's likely enough for the most
 users.

 What do you think about making the URL mode as default like it was in CODI
 before?

 Regards,
 Thomas