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 it was 

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 

Ideas on ClientWindow handling / refactoring

2014-01-10 Thread Thomas Andraschko
Based on the discussion in JSF - default ClientWindowRenderMode?:

 struberg:
 The windowId is added as root element to the view tree.

You mean that the dsPostWindowId input is added as direct form child. Right?

Posting it with default ajax options should work fine with PrimeFaces.
The only difference is our partialSubmit modus, which only collects the
values from the processed components.
So if you only process e.g. input1 input2, the hidden inputs on the form
won't processed.
Updating the ViewState is a custom logic with partialSubmit.

Maybe it should be handled better on PrimeFaces side but I think it would
be better the store the windowId in the WindowIdComponent.
It works for all cases and it don't requires any JS or compontlib
compatibility.
It's just stored the windowId in the ViewRoot which is always available for
postbacks.
Or will it have other drawbacks?


About windowhandler.js/html:
What about moving the whole JS stuff to the windowhandler.js?
We could parse the windowhandler html string on the server and parse JSF
resource includes. So we could easily include our windowhandler.js.
The user can also import other resources like css.

I already done this for a custom JSF 2.2 ClientWindow - works fine.

I think we should also render the ClientWindowRenderMode to the client, so
that the windowhandler only handles CLIENTWINDOW and not e.g. URL.
I would refactor the windowhandler.js, that it must be initialized via a JS
call - DSWindowContext.init(windowId, clientWindowRenderMode);
We could simply render that script via our WindowIdComponentHtmlRenderer.


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: Ideas on ClientWindow handling / refactoring

2014-01-10 Thread Thomas Andraschko
Hi Gerhard,

thats true. Therefore we added extra processing of
javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces :)
Don't know if Cagatay would accept that i add workarounds for DS in
PrimeFaces. Therefore adding the windowId e.g. to the ViewMap would be a
safer way.

Regards,
Thomas


2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com

 @thomas:
 with jsf 2.2+ it's different.
 the window-id is (/should be) also used (if enabled) to find the correct
 state.
 - any compliant request needs to include the window-id (if enabled).

 regards,
 gerhard



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

  Based on the discussion in JSF - default ClientWindowRenderMode?:
 
   struberg:
   The windowId is added as root element to the view tree.
 
  You mean that the dsPostWindowId input is added as direct form child.
  Right?
 
  Posting it with default ajax options should work fine with PrimeFaces.
  The only difference is our partialSubmit modus, which only collects the
  values from the processed components.
  So if you only process e.g. input1 input2, the hidden inputs on the
 form
  won't processed.
  Updating the ViewState is a custom logic with partialSubmit.
 
  Maybe it should be handled better on PrimeFaces side but I think it would
  be better the store the windowId in the WindowIdComponent.
  It works for all cases and it don't requires any JS or compontlib
  compatibility.
  It's just stored the windowId in the ViewRoot which is always available
 for
  postbacks.
  Or will it have other drawbacks?
 
 
  About windowhandler.js/html:
  What about moving the whole JS stuff to the windowhandler.js?
  We could parse the windowhandler html string on the server and parse JSF
  resource includes. So we could easily include our windowhandler.js.
  The user can also import other resources like css.
 
  I already done this for a custom JSF 2.2 ClientWindow - works fine.
 
  I think we should also render the ClientWindowRenderMode to the client,
 so
  that the windowhandler only handles CLIENTWINDOW and not e.g. URL.
  I would refactor the windowhandler.js, that it must be initialized via a
 JS
  call - DSWindowContext.init(windowId, clientWindowRenderMode);
  We could simply render that script via our WindowIdComponentHtmlRenderer.
 



Re: Ideas on ClientWindow handling / refactoring

2014-01-10 Thread Thomas Andraschko
Saving the windowId for postbacks in the ViewMap, would be really a much
easier, more compatible and safer way than adding hidden inputs via JS.


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

 Hi Gerhard,

 thats true. Therefore we added extra processing of
 javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces :)
 Don't know if Cagatay would accept that i add workarounds for DS in
 PrimeFaces. Therefore adding the windowId e.g. to the ViewMap would be a
 safer way.

 Regards,
 Thomas


 2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com

 @thomas:
 with jsf 2.2+ it's different.
 the window-id is (/should be) also used (if enabled) to find the correct
 state.
 - any compliant request needs to include the window-id (if enabled).

 regards,
 gerhard



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

  Based on the discussion in JSF - default ClientWindowRenderMode?:
 
   struberg:
   The windowId is added as root element to the view tree.
 
  You mean that the dsPostWindowId input is added as direct form child.
  Right?
 
  Posting it with default ajax options should work fine with PrimeFaces.
  The only difference is our partialSubmit modus, which only collects the
  values from the processed components.
  So if you only process e.g. input1 input2, the hidden inputs on the
 form
  won't processed.
  Updating the ViewState is a custom logic with partialSubmit.
 
  Maybe it should be handled better on PrimeFaces side but I think it
 would
  be better the store the windowId in the WindowIdComponent.
  It works for all cases and it don't requires any JS or compontlib
  compatibility.
  It's just stored the windowId in the ViewRoot which is always available
 for
  postbacks.
  Or will it have other drawbacks?
 
 
  About windowhandler.js/html:
  What about moving the whole JS stuff to the windowhandler.js?
  We could parse the windowhandler html string on the server and parse JSF
  resource includes. So we could easily include our windowhandler.js.
  The user can also import other resources like css.
 
  I already done this for a custom JSF 2.2 ClientWindow - works fine.
 
  I think we should also render the ClientWindowRenderMode to the client,
 so
  that the windowhandler only handles CLIENTWINDOW and not e.g. URL.
  I would refactor the windowhandler.js, that it must be initialized via
 a JS
  call - DSWindowContext.init(windowId, clientWindowRenderMode);
  We could simply render that script via our
 WindowIdComponentHtmlRenderer.
 





Re: Ideas on ClientWindow handling / refactoring

2014-01-10 Thread Mark Struberg
we probably should do both.

LieGrue,
strub




- Original Message -
 From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org dev@deltaspike.apache.org
 Cc: 
 Sent: Friday, 10 January 2014, 16:56
 Subject: Re: Ideas on ClientWindow handling / refactoring
 
 Saving the windowId for postbacks in the ViewMap, would be really a much
 easier, more compatible and safer way than adding hidden inputs via JS.
 
 
 
 2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
 
  Hi Gerhard,
 
  thats true. Therefore we added extra processing of
  javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces :)
  Don't know if Cagatay would accept that i add workarounds for DS in
  PrimeFaces. Therefore adding the windowId e.g. to the ViewMap would be a
  safer way.
 
  Regards,
  Thomas
 
 
  2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com
 
  @thomas:
  with jsf 2.2+ it's different.
  the window-id is (/should be) also used (if enabled) to find the 
 correct
  state.
  - any compliant request needs to include the window-id (if 
 enabled).
 
  regards,
  gerhard
 
 
 
  2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
 
   Based on the discussion in JSF - default 
 ClientWindowRenderMode?:
  
struberg:
The windowId is added as root element to the view tree.
  
   You mean that the dsPostWindowId input is added as direct form 
 child.
   Right?
  
   Posting it with default ajax options should work fine with 
 PrimeFaces.
   The only difference is our partialSubmit modus, which only 
 collects the
   values from the processed components.
   So if you only process e.g. input1 input2, the hidden 
 inputs on the
  form
   won't processed.
   Updating the ViewState is a custom logic with partialSubmit.
  
   Maybe it should be handled better on PrimeFaces side but I think 
 it
  would
   be better the store the windowId in the WindowIdComponent.
   It works for all cases and it don't requires any JS or 
 compontlib
   compatibility.
   It's just stored the windowId in the ViewRoot which is always 
 available
  for
   postbacks.
   Or will it have other drawbacks?
  
  
   About windowhandler.js/html:
   What about moving the whole JS stuff to the windowhandler.js?
   We could parse the windowhandler html string on the server and 
 parse JSF
   resource includes. So we could easily include our 
 windowhandler.js.
   The user can also import other resources like css.
  
   I already done this for a custom JSF 2.2 ClientWindow - works 
 fine.
  
   I think we should also render the ClientWindowRenderMode to the 
 client,
  so
   that the windowhandler only handles CLIENTWINDOW and not e.g. URL.
   I would refactor the windowhandler.js, that it must be initialized 
 via
  a JS
   call - DSWindowContext.init(windowId, clientWindowRenderMode);
   We could simply render that script via our
  WindowIdComponentHtmlRenderer.
  
 
 
 
 


Re: Ideas on ClientWindow handling / refactoring

2014-01-10 Thread Gerhard Petracek
as a (deactivatable) fallback the view-map would be fine (we couldn't use
it in codi, because we had to support jsf 1.2.x as well)

regards,
gerhard



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

 we probably should do both.

 LieGrue,
 strub




 - Original Message -
  From: Thomas Andraschko andraschko.tho...@gmail.com
  To: dev@deltaspike.apache.org dev@deltaspike.apache.org
  Cc:
  Sent: Friday, 10 January 2014, 16:56
  Subject: Re: Ideas on ClientWindow handling / refactoring
 
  Saving the windowId for postbacks in the ViewMap, would be really a much
  easier, more compatible and safer way than adding hidden inputs via JS.
 
 
 
  2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
 
   Hi Gerhard,
 
   thats true. Therefore we added extra processing of
   javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces :)
   Don't know if Cagatay would accept that i add workarounds for DS in
   PrimeFaces. Therefore adding the windowId e.g. to the ViewMap would be
 a
   safer way.
 
   Regards,
   Thomas
 
 
   2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com
 
   @thomas:
   with jsf 2.2+ it's different.
   the window-id is (/should be) also used (if enabled) to find the
  correct
   state.
   - any compliant request needs to include the window-id (if
  enabled).
 
   regards,
   gerhard
 
 
 
   2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
 
Based on the discussion in JSF - default
  ClientWindowRenderMode?:
   
 struberg:
 The windowId is added as root element to the view tree.
   
You mean that the dsPostWindowId input is added as direct form
  child.
Right?
   
Posting it with default ajax options should work fine with
  PrimeFaces.
The only difference is our partialSubmit modus, which only
  collects the
values from the processed components.
So if you only process e.g. input1 input2, the hidden
  inputs on the
   form
won't processed.
Updating the ViewState is a custom logic with partialSubmit.
   
Maybe it should be handled better on PrimeFaces side but I think
  it
   would
be better the store the windowId in the WindowIdComponent.
It works for all cases and it don't requires any JS or
  compontlib
compatibility.
It's just stored the windowId in the ViewRoot which is always
  available
   for
postbacks.
Or will it have other drawbacks?
   
   
About windowhandler.js/html:
What about moving the whole JS stuff to the windowhandler.js?
We could parse the windowhandler html string on the server and
  parse JSF
resource includes. So we could easily include our
  windowhandler.js.
The user can also import other resources like css.
   
I already done this for a custom JSF 2.2 ClientWindow - works
  fine.
   
I think we should also render the ClientWindowRenderMode to the
  client,
   so
that the windowhandler only handles CLIENTWINDOW and not e.g. URL.
I would refactor the windowhandler.js, that it must be initialized
  via
   a JS
call - DSWindowContext.init(windowId, clientWindowRenderMode);
We could simply render that script via our
   WindowIdComponentHtmlRenderer.
   
 
 
 
 



Re: [VOTE] Get rid of @Web in the servlet module

2014-01-10 Thread Christian Kaltepoth
-1
I think we should use a qualifier for producers of types that aren't ours
to prevent conflicts.

Christian


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

 -1 (non blocking of course).
 Because there are already other producers for some of the resources in
 question and the vetoing is really an ugly and error prone workaround.

 LieGrue,
 strub





 
  From: Gerhard Petracek gerhard.petra...@gmail.com
 To: dev@deltaspike.apache.org
 Sent: Wednesday, 8 January 2014, 0:30
 Subject: Re: [VOTE] Get rid of @Web in the servlet module
 
 
 +1 since we haven't seen a technical reason which would block this
 simplification
 
 regards,
 gerhard
 
 
 
 
 2014/1/7 Romain Manni-Bucau rmannibu...@gmail.com
 
  +0
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2014/1/7 Thomas Andraschko andraschko.tho...@gmail.com:
   Hi all,
  
   based on the discusstion in Servlet Module - Do we really need
 @Web? so
   far, I'd like to call a vote.
  
   +1 get rid of @Web
   +0 no opinion
   -1 keep it
  
   Please vote.
  
   Regards,
   Thomas
 
 
 
 




-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal


Re: Ideas on ClientWindow handling / refactoring

2014-01-10 Thread Thomas Andraschko
but why should we keep the JS logic instead of ViewMap?
Are there any drawbacks when we store it in the ViewMap?

The current implementations looks soo complex, but actually it isn't that
complex. So therefore i would like to get rid of not required code.


2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com

 as a (deactivatable) fallback the view-map would be fine (we couldn't use
 it in codi, because we had to support jsf 1.2.x as well)

 regards,
 gerhard



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

  we probably should do both.
 
  LieGrue,
  strub
 
 
 
 
  - Original Message -
   From: Thomas Andraschko andraschko.tho...@gmail.com
   To: dev@deltaspike.apache.org dev@deltaspike.apache.org
   Cc:
   Sent: Friday, 10 January 2014, 16:56
   Subject: Re: Ideas on ClientWindow handling / refactoring
  
   Saving the windowId for postbacks in the ViewMap, would be really a
 much
   easier, more compatible and safer way than adding hidden inputs via JS.
  
  
  
   2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
  
Hi Gerhard,
  
thats true. Therefore we added extra processing of
javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces :)
Don't know if Cagatay would accept that i add workarounds for DS in
PrimeFaces. Therefore adding the windowId e.g. to the ViewMap would
 be
  a
safer way.
  
Regards,
Thomas
  
  
2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com
  
@thomas:
with jsf 2.2+ it's different.
the window-id is (/should be) also used (if enabled) to find the
   correct
state.
- any compliant request needs to include the window-id (if
   enabled).
  
regards,
gerhard
  
  
  
2014/1/10 Thomas Andraschko andraschko.tho...@gmail.com
  
 Based on the discussion in JSF - default
   ClientWindowRenderMode?:

  struberg:
  The windowId is added as root element to the view tree.

 You mean that the dsPostWindowId input is added as direct form
   child.
 Right?

 Posting it with default ajax options should work fine with
   PrimeFaces.
 The only difference is our partialSubmit modus, which only
   collects the
 values from the processed components.
 So if you only process e.g. input1 input2, the hidden
   inputs on the
form
 won't processed.
 Updating the ViewState is a custom logic with partialSubmit.

 Maybe it should be handled better on PrimeFaces side but I think
   it
would
 be better the store the windowId in the WindowIdComponent.
 It works for all cases and it don't requires any JS or
   compontlib
 compatibility.
 It's just stored the windowId in the ViewRoot which is always
   available
for
 postbacks.
 Or will it have other drawbacks?


 About windowhandler.js/html:
 What about moving the whole JS stuff to the windowhandler.js?
 We could parse the windowhandler html string on the server and
   parse JSF
 resource includes. So we could easily include our
   windowhandler.js.
 The user can also import other resources like css.

 I already done this for a custom JSF 2.2 ClientWindow - works
   fine.

 I think we should also render the ClientWindowRenderMode to the
   client,
so
 that the windowhandler only handles CLIENTWINDOW and not e.g. URL.
 I would refactor the windowhandler.js, that it must be initialized
   via
a JS
 call - DSWindowContext.init(windowId, clientWindowRenderMode);
 We could simply render that script via our
WindowIdComponentHtmlRenderer.

  
  
  
  
 



Re: Ideas on ClientWindow handling / refactoring

2014-01-10 Thread Thomas Andraschko
Hmm right - but we could also move windowContext#activateWindow to a
AFTER_RESTORE_VIEW phase listener?
AFAIK RESTORE_VIEW shouldn't touch any beans?


2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com

 we need to restore the window-id before the lifecycle starts.

 regards,
 gerhard



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

  but why should we keep the JS logic instead of ViewMap?
  Are there any drawbacks when we store it in the ViewMap?
 
  The current implementations looks soo complex, but actually it isn't that
  complex. So therefore i would like to get rid of not required code.
 
 
  2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com
 
   as a (deactivatable) fallback the view-map would be fine (we couldn't
 use
   it in codi, because we had to support jsf 1.2.x as well)
  
   regards,
   gerhard
  
  
  
   2014/1/10 Mark Struberg strub...@yahoo.de
  
we probably should do both.
   
LieGrue,
strub
   
   
   
   
- Original Message -
 From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org dev@deltaspike.apache.org
 Cc:
 Sent: Friday, 10 January 2014, 16:56
 Subject: Re: Ideas on ClientWindow handling / refactoring

 Saving the windowId for postbacks in the ViewMap, would be really a
   much
 easier, more compatible and safer way than adding hidden inputs via
  JS.



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

  Hi Gerhard,

  thats true. Therefore we added extra processing of
  javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces :)
  Don't know if Cagatay would accept that i add workarounds for DS
 in
  PrimeFaces. Therefore adding the windowId e.g. to the ViewMap
 would
   be
a
  safer way.

  Regards,
  Thomas


  2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com

  @thomas:
  with jsf 2.2+ it's different.
  the window-id is (/should be) also used (if enabled) to find the
 correct
  state.
  - any compliant request needs to include the window-id (if
 enabled).

  regards,
  gerhard



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

   Based on the discussion in JSF - default
 ClientWindowRenderMode?:
  
struberg:
The windowId is added as root element to the view tree.
  
   You mean that the dsPostWindowId input is added as direct form
 child.
   Right?
  
   Posting it with default ajax options should work fine with
 PrimeFaces.
   The only difference is our partialSubmit modus, which only
 collects the
   values from the processed components.
   So if you only process e.g. input1 input2, the hidden
 inputs on the
  form
   won't processed.
   Updating the ViewState is a custom logic with partialSubmit.
  
   Maybe it should be handled better on PrimeFaces side but I
 think
 it
  would
   be better the store the windowId in the WindowIdComponent.
   It works for all cases and it don't requires any JS or
 compontlib
   compatibility.
   It's just stored the windowId in the ViewRoot which is always
 available
  for
   postbacks.
   Or will it have other drawbacks?
  
  
   About windowhandler.js/html:
   What about moving the whole JS stuff to the windowhandler.js?
   We could parse the windowhandler html string on the server and
 parse JSF
   resource includes. So we could easily include our
 windowhandler.js.
   The user can also import other resources like css.
  
   I already done this for a custom JSF 2.2 ClientWindow - works
 fine.
  
   I think we should also render the ClientWindowRenderMode to
 the
 client,
  so
   that the windowhandler only handles CLIENTWINDOW and not e.g.
  URL.
   I would refactor the windowhandler.js, that it must be
  initialized
 via
  a JS
   call - DSWindowContext.init(windowId,
 clientWindowRenderMode);
   We could simply render that script via our
  WindowIdComponentHtmlRenderer.
  




   
  
 



Re: Ideas on ClientWindow handling / refactoring

2014-01-10 Thread Thomas Andraschko
(of course it would only be required #ifPostback)


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

 Hmm right - but we could also move windowContext#activateWindow to a
 AFTER_RESTORE_VIEW phase listener?
 AFAIK RESTORE_VIEW shouldn't touch any beans?


 2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com

 we need to restore the window-id before the lifecycle starts.

 regards,
 gerhard



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

  but why should we keep the JS logic instead of ViewMap?
  Are there any drawbacks when we store it in the ViewMap?
 
  The current implementations looks soo complex, but actually it isn't
 that
  complex. So therefore i would like to get rid of not required code.
 
 
  2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com
 
   as a (deactivatable) fallback the view-map would be fine (we couldn't
 use
   it in codi, because we had to support jsf 1.2.x as well)
  
   regards,
   gerhard
  
  
  
   2014/1/10 Mark Struberg strub...@yahoo.de
  
we probably should do both.
   
LieGrue,
strub
   
   
   
   
- Original Message -
 From: Thomas Andraschko andraschko.tho...@gmail.com
 To: dev@deltaspike.apache.org dev@deltaspike.apache.org
 Cc:
 Sent: Friday, 10 January 2014, 16:56
 Subject: Re: Ideas on ClientWindow handling / refactoring

 Saving the windowId for postbacks in the ViewMap, would be really
 a
   much
 easier, more compatible and safer way than adding hidden inputs
 via
  JS.



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

  Hi Gerhard,

  thats true. Therefore we added extra processing of
  javax.faces.ViewState+javax.faces.ClientWindow in PrimeFaces :)
  Don't know if Cagatay would accept that i add workarounds for
 DS in
  PrimeFaces. Therefore adding the windowId e.g. to the ViewMap
 would
   be
a
  safer way.

  Regards,
  Thomas


  2014/1/10 Gerhard Petracek gerhard.petra...@gmail.com

  @thomas:
  with jsf 2.2+ it's different.
  the window-id is (/should be) also used (if enabled) to find
 the
 correct
  state.
  - any compliant request needs to include the window-id (if
 enabled).

  regards,
  gerhard



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

   Based on the discussion in JSF - default
 ClientWindowRenderMode?:
  
struberg:
The windowId is added as root element to the view tree.
  
   You mean that the dsPostWindowId input is added as direct
 form
 child.
   Right?
  
   Posting it with default ajax options should work fine with
 PrimeFaces.
   The only difference is our partialSubmit modus, which only
 collects the
   values from the processed components.
   So if you only process e.g. input1 input2, the hidden
 inputs on the
  form
   won't processed.
   Updating the ViewState is a custom logic with partialSubmit.
  
   Maybe it should be handled better on PrimeFaces side but I
 think
 it
  would
   be better the store the windowId in the WindowIdComponent.
   It works for all cases and it don't requires any JS or
 compontlib
   compatibility.
   It's just stored the windowId in the ViewRoot which is always
 available
  for
   postbacks.
   Or will it have other drawbacks?
  
  
   About windowhandler.js/html:
   What about moving the whole JS stuff to the windowhandler.js?
   We could parse the windowhandler html string on the server
 and
 parse JSF
   resource includes. So we could easily include our
 windowhandler.js.
   The user can also import other resources like css.
  
   I already done this for a custom JSF 2.2 ClientWindow - works
 fine.
  
   I think we should also render the ClientWindowRenderMode to
 the
 client,
  so
   that the windowhandler only handles CLIENTWINDOW and not e.g.
  URL.
   I would refactor the windowhandler.js, that it must be
  initialized
 via
  a JS
   call - DSWindowContext.init(windowId,
 clientWindowRenderMode);
   We could simply render that script via our
  WindowIdComponentHtmlRenderer.