date:20071220

Re: [Vote] release for myfaces 1.2.1

2007-12-20 Thread Martin Marinschek

Is this still a vote now?

Can we start a separate thread?

regards,

Martin

On 12/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 the plugin includes the notice/license
 if not present, it generates them

 -M

 On Dec 20, 2007 8:06 AM, simon [EMAIL PROTECTED] wrote:
 
  On Thu, 2007-12-20 at 07:52 +0100, Matthias Wessendorf wrote:
As it happens, there is quite a vigorous discussion going on right now
in both apache commons and legal-discuss lists regarding NOTICE and
LICENSE files. Some people would like to use a maven feature to
auto-generate LICENSE and NOTICE files. This is quite controversial,
though, and a number of people prefer the existing apache-commons way
(including myself).
  
   I like having them in the root folder, like done in Trinidad
   https://svn.apache.org/repos/asf/myfaces/trinidad/trunk_1.2.x/
  
   but, the auto-generation plugins is fine for including them in
   every JAR. Trinidad uses that plugin as well.
 
  ??
 
  Do you mean there is a license and notice checked in, but the built jar
  ignores these and uses something different instead? That sounds like the
  worst of both worlds to me. It would:
  (a) double the work, as *both* need to be checked for correctness, and
  (b) is really confusing for users if they differ.
 
 
  Regards,
 
  Simon
 
 



 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 mail: matzew-at-apache-dot-org



-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [Vote] release for Trinidad Plugins 1.2.6

2007-12-20 Thread Martin Marinschek

+1

regards,

Martin

On 12/20/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
 +1

 Matthias Wessendorf schrieb:
  yes,
  that is correct.
 
  -M
 
  On Dec 20, 2007 8:27 AM, Bernd Bohmann [EMAIL PROTECTED] wrote:
  Hello,
 
  are the release notes correct?
 
 
 http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661styleName=Htmlversion=12312879
 
  Regards
 
  Bernd
 
  Matthias Wessendorf schrieb:
 
  +1
 
  On Dec 20, 2007 7:39 AM, Leonardo Uribe [EMAIL PROTECTED] wrote:
  Hi,
 
  I was running the needed tasks to get the 1.2.6 release of Trinidad
  Plugins out.
 
  This task is necessary for release Myfaces 1.2.1, because it uses faces
 plugin.
 
  Please note that this vote concerns all of the following parts:
   1. Maven artifact group org.apache.myfaces.trinidadbuild v 1.2.6 [1]
 
  The artifacts are deployed to my private Apache account ([1]).
 
  Please take a look at the 1.2.6 artifacts and vote!
 
  Please note: This vote is majority approval with a minimum of three
  +1 votes (see [3]).
 
  --
  --
  [ ] +1 for community members who have reviewed the bits
  [ ] +0
  [ ] -1 for fatal flaws that should cause these bits not to be released,
 and why..
  
 
  Thanks,
  Leonardo Uribe
 
  [1] http://people.apache.org/~lu4242/trinidad-build126
  [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 
 
 
 
 
 



-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Server state saving and multiple frames

2007-12-20 Thread Martin Marinschek

Hi Nicu,

we should include Mario in this discussion - he implemented a solution
for this in Orchestra. Also, how about Trinidad, in Trinidad there is
dialog handling as well, how is this done?

regards,

Martin

On 12/19/07, simon [EMAIL PROTECTED] wrote:
 Hi Nicu,

 I haven't got time to look at this closely, but IMO siomething like this
 is definitely needed in MyFaces. A user with multiple windows is
 certainly going to have trouble at the moment.

 I think a modification to the view pool to include a window id (or
 frame id) is definitely a good idea.

 The second part of the problem still remains: how to associate a
 different id with each window/frame. Checking CommandLink components for
 a target attribute is clever; it doesn't solve all the cases but does
 solve some.

 Regards,

 Simon

 On Tue, 2007-12-18 at 19:07 +0200, Nicu Mercioiu wrote:
  Hi,
 
There is a problem in JSF when more than one window are opened
  in an application.
  There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION  view
  states saved at one moment (when server side state saving is enabled).
  If you have 2 windows opened and you navigate on one of them for
  NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's
  state.
 
  I've been facing this problem while developing a project so I've
  implemented a solution for it.
 
 The solution is having a number of view states saved for each
  opened window at one moment.
  For determining when a new window (frame) is opened, the target of the
  submitting component (or its enclosing form) is used.
  This is obtained in the HtmlLinkRendererBase's and
  HtmlButtonRendererBase's decode methods and it is set in the
  RequestMap.
  Using the submitted target, the JspStateManagerImpl figures out
  whether a new frame was opened.
  If so, a new frame id is generated.
  In the renderResponse phase, the frameId is encoded in the
  javax.faces.ViewState field
  and is used along with the viewId to save the state in a
  SerializedViewCollection.
  In the restore view phase the frameId is decoded from the
  javax.faces.ViewState field
  and is used along with the viewId to restore the corresponding state
  from the SerializedViewCollection.
 
 In SerializedViewCollection instead of a list of recently used
  views, now a list is kept for each frameId.
  The following context params are defined for configuring this.
  NUMBER_OF_FRAMES_IN_SESSION (max frames stored)
  NUMBER_OF_VIEWS_IN_FRAME (max views stored per frame)
  These replace the old: NUMBER_OF_VIEWS_IN_SESSION context-param.
 
 
  What is your opinion on this solution?
 
Of course this solution only works with MyFaces Tomahawk's
  commandLink and commandButton.
  Ohter component sets that do not use a custom stateManager might use
  this feature
  if they will just modify the renderers of command components to set
  the target attribute in the requestMap.
 
An extra feature would be to enable this for outputLinks (plain
  old links) and for JS (openWindow).
  The solution for this is quite simple, just add a GET parameter named
  'target' and set the value the same as the target attribute.
  In the JspStateManagerImpl this value is obtained from the
  requestParameterMap and used the same as in the other case.
  Do you think this would be useful too?
 
  Regards,
  Nicu




-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[jira] Commented: (TRINIDAD-845) choice between IFrame-PPR or XHR should be possible

2007-12-20 Thread Michael Kutsch (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553610
]

Michael Kutsch commented on TRINIDAD-845:
-

We have the same problem. I am working for an insurance company and our new
calculator for insurances will run on trinidad and use PPR. Since internally
we use IE6 we cannot switch to XHR based newer versions. The calculator will be
used by resellers too. I don't see that we can get them all to use IE7 or
Firefox.

The choice of the communication mechanism PPR or XHR is very important.

choice between IFrame-PPR or XHR should be possible

Key: TRINIDAD-845
URL: https://issues.apache.org/jira/browse/TRINIDAD-845
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.2-core
Reporter: Jan Görß

It should be possible to change the interactive server communication between
IFrame-PPR and XHR.
Our customers are banking houses and they define the security constrains
(IE5.5+ with deactived ActiveX).
IE 5.5 - 6 are the problem.
IE 7 has a possibility to run XHR without ActiveX.
At the beginning of our projects we decide to take Trinidad because of it's
IFrame-PPR solution and our WebApps must run without AJAX.
I think other users of trinidad have the same problem also.
Taken from [EMAIL PROTECTED]
Hi,
I know all the issues with not able to use IE w/ activated ActiveX.
Sure, a solution is possible, but it is (as always) a matter of time.
Are you willing to help out on this?
I'll also check our internal requirements, since we have also customers, that
may upgrade
to Trinidad, coming from ADF Faces 10.x.
Can you file an issue in our jira w/ some details, that we don't forget it?
Thx,
Matthias
On Nov 28, 2007 1:38 PM, Goerss, Jan [EMAIL PROTECTED] wrote:

The problem is that our customers are banking houses.
They define the security constrains (IE5.5+ with deactivated ActiveX).

We use Trinidad 1.2.1 and we can't switch to latest version of Trinidad
with AJAX.

I hope, a fallback option is possible, otherwise we can't use the latest
version of Trinidad and our project can work with Trinidad version 1.2.1
only.
The problems are with this constrain:
- we get no bugfixing more
- we can't use new components and features (new releases)
- we can't use new trinidad development

I hope a solution is possible.

Thanks,

Jan

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag
von Matthias Wessendorf
Gesendet: Mittwoch, 28. November 2007 11:04
An: MyFaces Discussion
Betreff: Re: Trinidad Ajax

Hi Jan,

yes, we switched to XHR with the release of 1.0.2 (and 1.2.2).
There is no way to use IFrame instead of XHR.

This will remain, because Ajax is pretty common these days and other
JSF-libs have that as well.

Providing an option to fallback might be possible, but not sure if
that will be done.

Is IE 5.5 really still supported by M$?
If not, I'd strongly recommend to kick that guy out.
Sure... only the IE7 doesn't require ActiveX for XHR, but IE does.

I am not aware of a solution for that.

Do you have any ideas ?

-Matthias

On Nov 28, 2007 10:48 AM, Goerss, Jan [EMAIL PROTECTED] wrote:

Hello all,

we noticed that MyFaces Trinidad is changing the PPR mechanism
towards real AJAX and the XmlHttpRequest object.

We are using Trinidad is the finance sector. There it is normal that
the clients use the Internet Explorer with deactivated ActiveX.

Furthermore they use not the newest browsers, so we although need to
support at least IE 5.5+.

At the beginning of our project we decide to take Trinidad because
of it's IFrame-PPR solution.

It seems as if it is not possible to choose between the two modes:
PPR or AJAX.

Will this remain? If so why? Otherwise, we think that a lot of
Trinidad library users will encounter problems with their clientsJ

Thanks in advance,

Jan

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Server state saving and multiple frames

2007-12-20 Thread Cristi Toth

Hi,

anyone is invited to contribute with ideas of course,
but I still don't understand what this (multiple-frames state saving) has to
do with dialog handling and conversations!?

On Dec 20, 2007 9:13 AM, Martin Marinschek [EMAIL PROTECTED]
wrote:

 Hi Nicu,

 we should include Mario in this discussion - he implemented a solution
 for this in Orchestra. Also, how about Trinidad, in Trinidad there is
 dialog handling as well, how is this done?

 regards,

 Martin

 On 12/19/07, simon [EMAIL PROTECTED] wrote:
  Hi Nicu,
 
  I haven't got time to look at this closely, but IMO siomething like this
  is definitely needed in MyFaces. A user with multiple windows is
  certainly going to have trouble at the moment.
 
  I think a modification to the view pool to include a window id (or
  frame id) is definitely a good idea.
 
  The second part of the problem still remains: how to associate a
  different id with each window/frame. Checking CommandLink components for
  a target attribute is clever; it doesn't solve all the cases but does
  solve some.
 
  Regards,
 
  Simon
 
  On Tue, 2007-12-18 at 19:07 +0200, Nicu Mercioiu wrote:
   Hi,
  
 There is a problem in JSF when more than one window are opened
   in an application.
   There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION  view
   states saved at one moment (when server side state saving is enabled).
   If you have 2 windows opened and you navigate on one of them for
   NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's
   state.
  
   I've been facing this problem while developing a project so I've
   implemented a solution for it.
  
  The solution is having a number of view states saved for each
   opened window at one moment.
   For determining when a new window (frame) is opened, the target of the
   submitting component (or its enclosing form) is used.
   This is obtained in the HtmlLinkRendererBase's and
   HtmlButtonRendererBase's decode methods and it is set in the
   RequestMap.
   Using the submitted target, the JspStateManagerImpl figures out
   whether a new frame was opened.
   If so, a new frame id is generated.
   In the renderResponse phase, the frameId is encoded in the
   javax.faces.ViewState field
   and is used along with the viewId to save the state in a
   SerializedViewCollection.
   In the restore view phase the frameId is decoded from the
   javax.faces.ViewState field
   and is used along with the viewId to restore the corresponding state
   from the SerializedViewCollection.
  
  In SerializedViewCollection instead of a list of recently used
   views, now a list is kept for each frameId.
   The following context params are defined for configuring this.
   NUMBER_OF_FRAMES_IN_SESSION (max frames stored)
   NUMBER_OF_VIEWS_IN_FRAME (max views stored per frame)
   These replace the old: NUMBER_OF_VIEWS_IN_SESSION context-param.
  
  
   What is your opinion on this solution?
  
 Of course this solution only works with MyFaces Tomahawk's
   commandLink and commandButton.
   Ohter component sets that do not use a custom stateManager might use
   this feature
   if they will just modify the renderers of command components to set
   the target attribute in the requestMap.
  
 An extra feature would be to enable this for outputLinks (plain
   old links) and for JS (openWindow).
   The solution for this is quite simple, just add a GET parameter named
   'target' and set the value the same as the target attribute.
   In the JspStateManagerImpl this value is obtained from the
   requestParameterMap and used the same as in the other case.
   Do you think this would be useful too?
  
   Regards,
   Nicu
 
 


 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces




-- 
Cristi Toth

-
Codebeat
www.codebeat.ro

[jira] Commented: (TRINIDAD-845) choice between IFrame-PPR or XHR should be possible

2007-12-20 Thread JIRA

[
https://issues.apache.org/jira/browse/TRINIDAD-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553613
]

Matthias Weßendorf commented on TRINIDAD-845:
-

IFrame or XHR you mean.
PPR is the Trinidad feature. The impl-detail was IFrame-based; now it is
XHR-based;

choice between IFrame-PPR or XHR should be possible

Key: TRINIDAD-845
URL: https://issues.apache.org/jira/browse/TRINIDAD-845
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.2-core
Reporter: Jan Görß

The problem is that our customers are banking houses.
They define the security constrains (IE5.5+ with deactivated ActiveX).

We use Trinidad 1.2.1 and we can't switch to latest version of Trinidad
with AJAX.

I hope a solution is possible.

Thanks,

Jan

Hi Jan,

yes, we switched to XHR with the release of 1.0.2 (and 1.2.2).
There is no way to use IFrame instead of XHR.

This will remain, because Ajax is pretty common these days and other
JSF-libs have that as well.

Providing an option to fallback might be possible, but not sure if
that will be done.

Is IE 5.5 really still supported by M$?
If not, I'd strongly recommend to kick that guy out.
Sure... only the IE7 doesn't require ActiveX for XHR, but IE does.

I am not aware of a solution for that.

Do you have any ideas ?

-Matthias

On Nov 28, 2007 10:48 AM, Goerss, Jan [EMAIL PROTECTED] wrote:

Hello all,

we noticed that MyFaces Trinidad is changing the PPR mechanism
towards real AJAX and the XmlHttpRequest object.

We are using Trinidad is the finance sector. There it is normal that
the clients use the Internet Explorer with deactivated ActiveX.

Furthermore they use not the newest browsers, so we although need to
support at least IE 5.5+.

At the beginning of our project we decide to take Trinidad because
of it's IFrame-PPR solution.

It seems as if it is not possible to choose between the two modes:
PPR or AJAX.

Will this remain? If so why? Otherwise, we think that a lot of
Trinidad library users will encounter problems with their clientsJ

Thanks in advance,

Jan

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Server state saving and multiple frames

2007-12-20 Thread Simon Kitching

Orchestra provides a tag that can be explicitly wrapped around links (eg 
h:outputLink). It then encodes a window id into the url params.

So it also partially addresses the second part of the problem (identifying 
windows/frames). It covers more cases than Nicu's suggestion, but it does 
require modifications to pages.

Orchestra then uses this window-id to provide a new set of conversation-scoped 
beans per window. But nothing in orchestra addresses the problem of the 
view-state pool, so unless I misunderstand something this Orchestra feature is 
not really usable; the backing beans will work right but when the viewstate 
gets screwed up after 4 page-views that is no consolation.

I think myfaces core needs to provide a per-window viewstate cache. It can then 
just allow something else to figure out how to identify the windows, allowing 
the Orchestra approach or Nicu's approach, or whatever people come up with.

Yes, it would be interesting to hear how Trinidad dialogs handle this..

Regards, 

Simon

 Martin Marinschek [EMAIL PROTECTED] schrieb:
 Hi Nicu,
 
 we should include Mario in this discussion - he implemented a solution
 for this in Orchestra. Also, how about Trinidad, in Trinidad there is
 dialog handling as well, how is this done?
 
 regards,
 
 Martin
 
 On 12/19/07, simon [EMAIL PROTECTED] wrote:
  Hi Nicu,
 
  I haven't got time to look at this closely, but IMO siomething like this
  is definitely needed in MyFaces. A user with multiple windows is
  certainly going to have trouble at the moment.
 
  I think a modification to the view pool to include a window id (or
  frame id) is definitely a good idea.
 
  The second part of the problem still remains: how to associate a
  different id with each window/frame. Checking CommandLink components for
  a target attribute is clever; it doesn't solve all the cases but does
  solve some.
 
  Regards,
 
  Simon
 
  On Tue, 2007-12-18 at 19:07 +0200, Nicu Mercioiu wrote:
   Hi,
  
 There is a problem in JSF when more than one window are opened
   in an application.
   There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION  view
   states saved at one moment (when server side state saving is enabled).
   If you have 2 windows opened and you navigate on one of them for
   NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's
   state.
  
   I've been facing this problem while developing a project so I've
   implemented a solution for it.
  
  The solution is having a number of view states saved for each
   opened window at one moment.
   For determining when a new window (frame) is opened, the target of the
   submitting component (or its enclosing form) is used.
   This is obtained in the HtmlLinkRendererBase's and
   HtmlButtonRendererBase's decode methods and it is set in the
   RequestMap.
   Using the submitted target, the JspStateManagerImpl figures out
   whether a new frame was opened.
   If so, a new frame id is generated.
   In the renderResponse phase, the frameId is encoded in the
   javax.faces.ViewState field
   and is used along with the viewId to save the state in a
   SerializedViewCollection.
   In the restore view phase the frameId is decoded from the
   javax.faces.ViewState field
   and is used along with the viewId to restore the corresponding state
   from the SerializedViewCollection.
  
  In SerializedViewCollection instead of a list of recently used
   views, now a list is kept for each frameId.
   The following context params are defined for configuring this.
   NUMBER_OF_FRAMES_IN_SESSION (max frames stored)
   NUMBER_OF_VIEWS_IN_FRAME (max views stored per frame)
   These replace the old: NUMBER_OF_VIEWS_IN_SESSION context-param.
  
  
   What is your opinion on this solution?
  
 Of course this solution only works with MyFaces Tomahawk's
   commandLink and commandButton.
   Ohter component sets that do not use a custom stateManager might use
   this feature
   if they will just modify the renderers of command components to set
   the target attribute in the requestMap.
  
 An extra feature would be to enable this for outputLinks (plain
   old links) and for JS (openWindow).
   The solution for this is quite simple, just add a GET parameter named
   'target' and set the value the same as the target attribute.
   In the JspStateManagerImpl this value is obtained from the
   requestParameterMap and used the same as in the other case.
   Do you think this would be useful too?
  
   Regards,
   Nicu
 
 
 
 
 -- 
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces

Re: [Vote] release for Trinidad Plugins 1.2.6

2007-12-20 Thread Bruno Aranda

+1

Thank you Leonardo!

Bruno

On 20/12/2007, Martin Marinschek [EMAIL PROTECTED] wrote:
 +1

 regards,

 Martin

 On 12/20/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
  +1
 
  Matthias Wessendorf schrieb:
   yes,
   that is correct.
  
   -M
  
   On Dec 20, 2007 8:27 AM, Bernd Bohmann [EMAIL PROTECTED] wrote:
   Hello,
  
   are the release notes correct?
  
  
  http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661styleName=Htmlversion=12312879
  
   Regards
  
   Bernd
  
   Matthias Wessendorf schrieb:
  
   +1
  
   On Dec 20, 2007 7:39 AM, Leonardo Uribe [EMAIL PROTECTED] wrote:
   Hi,
  
   I was running the needed tasks to get the 1.2.6 release of Trinidad
   Plugins out.
  
   This task is necessary for release Myfaces 1.2.1, because it uses faces
  plugin.
  
   Please note that this vote concerns all of the following parts:
1. Maven artifact group org.apache.myfaces.trinidadbuild v 1.2.6 [1]
  
   The artifacts are deployed to my private Apache account ([1]).
  
   Please take a look at the 1.2.6 artifacts and vote!
  
   Please note: This vote is majority approval with a minimum of three
   +1 votes (see [3]).
  
   --
   --
   [ ] +1 for community members who have reviewed the bits
   [ ] +0
   [ ] -1 for fatal flaws that should cause these bits not to be released,
  and why..
   
  
   Thanks,
   Leonardo Uribe
  
   [1] http://people.apache.org/~lu4242/trinidad-build126
   [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
  
  
  
  
  
  
 


 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces

[jira] Commented: (TRINIDAD-845) choice between IFrame-PPR or XHR should be possible

2007-12-20 Thread JIRA

[
https://issues.apache.org/jira/browse/TRINIDAD-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553615
]

Matthias Weßendorf commented on TRINIDAD-845:
-

Michael,
does IE6 supports XHR, but only via ActiveX.
Does that mean, you have ActiveX disabled as well ?

choice between IFrame-PPR or XHR should be possible

Key: TRINIDAD-845
URL: https://issues.apache.org/jira/browse/TRINIDAD-845
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.2-core
Reporter: Jan Görß

The problem is that our customers are banking houses.
They define the security constrains (IE5.5+ with deactivated ActiveX).

We use Trinidad 1.2.1 and we can't switch to latest version of Trinidad
with AJAX.

I hope a solution is possible.

Thanks,

Jan

Hi Jan,

yes, we switched to XHR with the release of 1.0.2 (and 1.2.2).
There is no way to use IFrame instead of XHR.

This will remain, because Ajax is pretty common these days and other
JSF-libs have that as well.

Providing an option to fallback might be possible, but not sure if
that will be done.

Is IE 5.5 really still supported by M$?
If not, I'd strongly recommend to kick that guy out.
Sure... only the IE7 doesn't require ActiveX for XHR, but IE does.

I am not aware of a solution for that.

Do you have any ideas ?

-Matthias

On Nov 28, 2007 10:48 AM, Goerss, Jan [EMAIL PROTECTED] wrote:

Hello all,

we noticed that MyFaces Trinidad is changing the PPR mechanism
towards real AJAX and the XmlHttpRequest object.

We are using Trinidad is the finance sector. There it is normal that
the clients use the Internet Explorer with deactivated ActiveX.

Furthermore they use not the newest browsers, so we although need to
support at least IE 5.5+.

At the beginning of our project we decide to take Trinidad because
of it's IFrame-PPR solution.

It seems as if it is not possible to choose between the two modes:
PPR or AJAX.

Will this remain? If so why? Otherwise, we think that a lot of
Trinidad library users will encounter problems with their clientsJ

Thanks in advance,

Jan

--
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Server state saving and multiple frames

2007-12-20 Thread Thomas Spiegl

Nicu's solution works fine for MyFaces commandLinks using the MyFaces
JspStateManager.
Someone using MyFaces Tomahawk can take advantage out of this new view
pool approach.

The big problem here: It does not work using a component library that
decorates the statemanager (eg. trinidad).
So far I did not take a look to trinidad's statesaving mechanism.
It'll be worth to think about a more common solution for
having a state view pool.

-Thomas

On Dec 20, 2007 9:41 AM, Simon Kitching [EMAIL PROTECTED] wrote:
 Orchestra provides a tag that can be explicitly wrapped around links (eg 
 h:outputLink). It then encodes a window id into the url params.

 So it also partially addresses the second part of the problem (identifying 
 windows/frames). It covers more cases than Nicu's suggestion, but it does 
 require modifications to pages.

 Orchestra then uses this window-id to provide a new set of 
 conversation-scoped beans per window. But nothing in orchestra addresses the 
 problem of the view-state pool, so unless I misunderstand something this 
 Orchestra feature is not really usable; the backing beans will work right but 
 when the viewstate gets screwed up after 4 page-views that is no consolation.

 I think myfaces core needs to provide a per-window viewstate cache. It can 
 then just allow something else to figure out how to identify the windows, 
 allowing the Orchestra approach or Nicu's approach, or whatever people come 
 up with.

 Yes, it would be interesting to hear how Trinidad dialogs handle this..

 Regards,

 Simon

  Martin Marinschek [EMAIL PROTECTED] schrieb:

  Hi Nicu,
 
  we should include Mario in this discussion - he implemented a solution
  for this in Orchestra. Also, how about Trinidad, in Trinidad there is
  dialog handling as well, how is this done?
 
  regards,
 
  Martin
 
  On 12/19/07, simon [EMAIL PROTECTED] wrote:
   Hi Nicu,
  
   I haven't got time to look at this closely, but IMO siomething like this
   is definitely needed in MyFaces. A user with multiple windows is
   certainly going to have trouble at the moment.
  
   I think a modification to the view pool to include a window id (or
   frame id) is definitely a good idea.
  
   The second part of the problem still remains: how to associate a
   different id with each window/frame. Checking CommandLink components for
   a target attribute is clever; it doesn't solve all the cases but does
   solve some.
  
   Regards,
  
   Simon
  
   On Tue, 2007-12-18 at 19:07 +0200, Nicu Mercioiu wrote:
Hi,
   
  There is a problem in JSF when more than one window are opened
in an application.
There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION  view
states saved at one moment (when server side state saving is enabled).
If you have 2 windows opened and you navigate on one of them for
NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's
state.
   
I've been facing this problem while developing a project so I've
implemented a solution for it.
   
   The solution is having a number of view states saved for each
opened window at one moment.
For determining when a new window (frame) is opened, the target of the
submitting component (or its enclosing form) is used.
This is obtained in the HtmlLinkRendererBase's and
HtmlButtonRendererBase's decode methods and it is set in the
RequestMap.
Using the submitted target, the JspStateManagerImpl figures out
whether a new frame was opened.
If so, a new frame id is generated.
In the renderResponse phase, the frameId is encoded in the
javax.faces.ViewState field
and is used along with the viewId to save the state in a
SerializedViewCollection.
In the restore view phase the frameId is decoded from the
javax.faces.ViewState field
and is used along with the viewId to restore the corresponding state
from the SerializedViewCollection.
   
   In SerializedViewCollection instead of a list of recently used
views, now a list is kept for each frameId.
The following context params are defined for configuring this.
NUMBER_OF_FRAMES_IN_SESSION (max frames stored)
NUMBER_OF_VIEWS_IN_FRAME (max views stored per frame)
These replace the old: NUMBER_OF_VIEWS_IN_SESSION context-param.
   
   
What is your opinion on this solution?
   
  Of course this solution only works with MyFaces Tomahawk's
commandLink and commandButton.
Ohter component sets that do not use a custom stateManager might use
this feature
if they will just modify the renderers of command components to set
the target attribute in the requestMap.
   
  An extra feature would be to enable this for outputLinks (plain
old links) and for JS (openWindow).
The solution for this is quite simple, just add a GET parameter named
'target' and set the value the same as the target attribute.
In the JspStateManagerImpl this value is obtained

[jira] Created: (MYFACES-1791) state management and multiple frames

2007-12-20 Thread Nicu Mercioiu (JIRA)

 state management and multiple frames
-

 Key: MYFACES-1791
 URL: https://issues.apache.org/jira/browse/MYFACES-1791
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions:  1.2.0, 1.1.5,  1.1.6-SNAPSHOT, 1.2.2-SNAPSHOT
Reporter: Nicu Mercioiu


There is a problem in JSF when more than one window are opened in an 
application. There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION  
view states saved at one moment (when server side state saving is enabled).
If 2 windows are opened and you navigate on one of them for 
NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's state. 



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

71 matches

Mail list logo