Re: [core] performance: performance hints
as much customisation as we want, but you always have to turn it on manually (e.g. via web.xml). Regards, Jakob 2011/4/26 Mark Struberg strub...@yahoo.de: heh, that reminds me of the quardrary logic of an old colleague: ja/nein/weißnicht/habangst (roughly translates to : yes/no/ihavenoidea/angst) :) LieGrue, strub --- On Tue, 4/26/11, Andy Schwartz andy.g.schwa...@gmail.com wrote: From: Andy Schwartz andy.g.schwa...@gmail.com Subject: Re: [core] performance: performance hints To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 26, 2011, 5:54 PM I think it is time to propose a new axiom relating to boolean properties. I would name it after Blake, who first called this truth to my attention: Blake's Axiom of Boolean Properties: You will regret making your property a boolean. :-) In this particular case, I am thinking about the UIData rowStatePreserved boolean property that we added in JSF 2.1. This currently has two values: 1. true: UIData performs state saving (ideally partial state saving) to save away row-specific properties. 2. false: UIData uses the old hacky mechanism for saving row-specific state (special casing EditableValueHolders and what not). In retrospect, it sure would have been nice to allow for a third value: 3. none: Don't make any attempt at state saving. Though now that UIData is stuck with a boolean type for this property, we don't have a simple way to support #3 (for UIData) that doesn't involve adding yet another attribute. In any case, I think it is fine to support this optimization one way or another (eg. along the lines discussed above). Of course, the magical ideal solution would be to come up with some clever way to automatically pick the best behavior. Or, failing that, it might be good to warn developers when they specify potentially conflicting values (such as disabling state saving for tables that stamp EditableValueHolders.) Andy -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] performance: performance hints
agree with Martin here, in all 6 points ;) The standard behavior of MyFaces core must always match with the spec (-- TCK). However, we can provide as much customisation as we want, but you always have to turn it on manually (e.g. via web.xml). Regards, Jakob 2011/4/26 Mark Struberg strub...@yahoo.de: heh, that reminds me of the quardrary logic of an old colleague: ja/nein/weißnicht/habangst (roughly translates to : yes/no/ihavenoidea/angst) :) LieGrue, strub --- On Tue, 4/26/11, Andy Schwartz andy.g.schwa...@gmail.com wrote: From: Andy Schwartz andy.g.schwa...@gmail.com Subject: Re: [core] performance: performance hints To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 26, 2011, 5:54 PM I think it is time to propose a new axiom relating to boolean properties. I would name it after Blake, who first called this truth to my attention: Blake's Axiom of Boolean Properties: You will regret making your property a boolean. :-) In this particular case, I am thinking about the UIData rowStatePreserved boolean property that we added in JSF 2.1. This currently has two values: 1. true: UIData performs state saving (ideally partial state saving) to save away row-specific properties. 2. false: UIData uses the old hacky mechanism for saving row-specific state (special casing EditableValueHolders and what not). In retrospect, it sure would have been nice to allow for a third value: 3. none: Don't make any attempt at state saving. Though now that UIData is stuck with a boolean type for this property, we don't have a simple way to support #3 (for UIData) that doesn't involve adding yet another attribute. In any case, I think it is fine to support this optimization one way or another (eg. along the lines discussed above). Of course, the magical ideal solution would be to come up with some clever way to automatically pick the best behavior. Or, failing that, it might be good to warn developers when they specify potentially conflicting values (such as disabling state saving for tables that stamp EditableValueHolders.) Andy -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] performance: performance hints
is found, make UIData skip automatically state saving code. Suggestions are welcome regards, Leonardo Uribe 2011/4/27 Jakob Korherr jakob.korh...@gmail.com Hi, I totally agree with Martin here, in all 6 points ;) The standard behavior of MyFaces core must always match with the spec (-- TCK). However, we can provide as much customisation as we want, but you always have to turn it on manually (e.g. via web.xml). Regards, Jakob 2011/4/26 Mark Struberg strub...@yahoo.de: heh, that reminds me of the quardrary logic of an old colleague: ja/nein/weißnicht/habangst (roughly translates to : yes/no/ihavenoidea/angst) :) LieGrue, strub --- On Tue, 4/26/11, Andy Schwartz andy.g.schwa...@gmail.com wrote: From: Andy Schwartz andy.g.schwa...@gmail.com Subject: Re: [core] performance: performance hints To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 26, 2011, 5:54 PM I think it is time to propose a new axiom relating to boolean properties. I would name it after Blake, who first called this truth to my attention: Blake's Axiom of Boolean Properties: You will regret making your property a boolean. :-) In this particular case, I am thinking about the UIData rowStatePreserved boolean property that we added in JSF 2.1. This currently has two values: 1. true: UIData performs state saving (ideally partial state saving) to save away row-specific properties. 2. false: UIData uses the old hacky mechanism for saving row-specific state (special casing EditableValueHolders and what not). In retrospect, it sure would have been nice to allow for a third value: 3. none: Don't make any attempt at state saving. Though now that UIData is stuck with a boolean type for this property, we don't have a simple way to support #3 (for UIData) that doesn't involve adding yet another attribute. In any case, I think it is fine to support this optimization one way or another (eg. along the lines discussed above). Of course, the magical ideal solution would be to come up with some clever way to automatically pick the best behavior. Or, failing that, it might be good to warn developers when they specify potentially conflicting values (such as disabling state saving for tables that stamp EditableValueHolders.) Andy -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] performance: performance hints
: Re: [core] performance: performance hints To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 26, 2011, 5:54 PM I think it is time to propose a new axiom relating to boolean properties. I would name it after Blake, who first called this truth to my attention: Blake's Axiom of Boolean Properties: You will regret making your property a boolean. :-) In this particular case, I am thinking about the UIData rowStatePreserved boolean property that we added in JSF 2.1. This currently has two values: 1. true: UIData performs state saving (ideally partial state saving) to save away row-specific properties. 2. false: UIData uses the old hacky mechanism for saving row-specific state (special casing EditableValueHolders and what not). In retrospect, it sure would have been nice to allow for a third value: 3. none: Don't make any attempt at state saving. Though now that UIData is stuck with a boolean type for this property, we don't have a simple way to support #3 (for UIData) that doesn't involve adding yet another attribute. In any case, I think it is fine to support this optimization one way or another (eg. along the lines discussed above). Of course, the magical ideal solution would be to come up with some clever way to automatically pick the best behavior. Or, failing that, it might be good to warn developers when they specify potentially conflicting values (such as disabling state saving for tables that stamp EditableValueHolders.) Andy -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] performance: performance hints
Hi, I totally agree with Martin here, in all 6 points ;) The standard behavior of MyFaces core must always match with the spec (-- TCK). However, we can provide as much customisation as we want, but you always have to turn it on manually (e.g. via web.xml). Regards, Jakob 2011/4/26 Mark Struberg strub...@yahoo.de: heh, that reminds me of the quardrary logic of an old colleague: ja/nein/weißnicht/habangst (roughly translates to : yes/no/ihavenoidea/angst) :) LieGrue, strub --- On Tue, 4/26/11, Andy Schwartz andy.g.schwa...@gmail.com wrote: From: Andy Schwartz andy.g.schwa...@gmail.com Subject: Re: [core] performance: performance hints To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 26, 2011, 5:54 PM I think it is time to propose a new axiom relating to boolean properties. I would name it after Blake, who first called this truth to my attention: Blake's Axiom of Boolean Properties: You will regret making your property a boolean. :-) In this particular case, I am thinking about the UIData rowStatePreserved boolean property that we added in JSF 2.1. This currently has two values: 1. true: UIData performs state saving (ideally partial state saving) to save away row-specific properties. 2. false: UIData uses the old hacky mechanism for saving row-specific state (special casing EditableValueHolders and what not). In retrospect, it sure would have been nice to allow for a third value: 3. none: Don't make any attempt at state saving. Though now that UIData is stuck with a boolean type for this property, we don't have a simple way to support #3 (for UIData) that doesn't involve adding yet another attribute. In any case, I think it is fine to support this optimization one way or another (eg. along the lines discussed above). Of course, the magical ideal solution would be to come up with some clever way to automatically pick the best behavior. Or, failing that, it might be good to warn developers when they specify potentially conflicting values (such as disabling state saving for tables that stamp EditableValueHolders.) Andy -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] performance: performance hints
Hi,
Leonardo Uribe píše v Po 25. 04. 2011 v 12:45 +0200:
Hi
2011/4/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
is it possible to introduce performance hints in myfaces-core?
Hints
similar to javax.faces.component.visit.VisitHint but related
to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently
there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must
extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve
it
elegantly - if present (in component.getAttributes()) UIData
skips
row-state-saving and restoring methods entirely.
Unfortunately, we can't do anything like that on default UIData
implementation
(it could breaks backwards behavior). I think we could include a
property
on tomahawk t:dataTable called readOnly, that just skip all that
code
related to save/restore for rows. That could be better, and it has
sense to
put in tomahawk, because after all that is the right location for
extend
default jsf components.
Yes, this is one point of view and I agree with that custom behaviour
belongs into custom component. I did exactly the same for my component.
But there are other topics to consider:
0) simple presence of performance hints in core does not break the
compatibility : the *usage* of that hint can break the compatibility -
so as usual, user must know what that parameter means and what it can
cause.
1) I think JSF implementation can break the specified functionality:
myfaces did it already with elResolvers sorting for example. But the
default must be always false for 100% compatibility with JSF
specification.
2) The hint technique is very common : another example from Java EE is
world JPA Query.setHint
3) Hints are a simple way to realize something this should be in core
but because of slow specification release cycle, you must wait a year or
two to get it officially specified in public API.
4) Ease of usage: for example, if you have only one readonly table in
whole project, creation of custom component for that purpose is an
overkill: simple f:attribute name=oam.readOnly value=true / is
much easier.
5) Internet is full of JSF is slow. Although I know that is completely
untrue, hinting the core for more performance is a easy way which
allows users to express all they need without additional dependencies.
So, do you think we really can't put this feature in core? I mean the
hints feature generally, not readonly UIData - that was only an
example.
Regards,
Kočičák
Anyway, I think it is possible to do some work on UIData to make it
perform
faster and better.
Lifespan of those hints can be request
(faceContext.attributes) or view
(component.attributes)
I don't think in this case it applies, but any configuration param for
a view
should be on a tag like f:view or something similar.
regards,
Leonardo
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
Re: [core] performance: performance hints
Hello Marin,
I don't see any problems to include this feature into MyFaces Core.
I don't think this breaks the specification:
h:dataTable
f:attribute name=readonly value=true /
/h:dataTable
Maybe we should also consider:
h:dataTable
h:column
f:attribute name=readonly value=true /
/h:column
/h:dataTable
From my point of view you should commit your suggestion to 1.1.x,
1.2.x, 2.0.x and 2.1.x.
Regards
Bernd
On Tue, Apr 26, 2011 at 5:13 PM, Martin Koci
martin.kocicak.k...@gmail.com wrote:
Hi,
Leonardo Uribe píše v Po 25. 04. 2011 v 12:45 +0200:
Hi
2011/4/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
is it possible to introduce performance hints in myfaces-core?
Hints
similar to javax.faces.component.visit.VisitHint but related
to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently
there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must
extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve
it
elegantly - if present (in component.getAttributes()) UIData
skips
row-state-saving and restoring methods entirely.
Unfortunately, we can't do anything like that on default UIData
implementation
(it could breaks backwards behavior). I think we could include a
property
on tomahawk t:dataTable called readOnly, that just skip all that
code
related to save/restore for rows. That could be better, and it has
sense to
put in tomahawk, because after all that is the right location for
extend
default jsf components.
Yes, this is one point of view and I agree with that custom behaviour
belongs into custom component. I did exactly the same for my component.
But there are other topics to consider:
0) simple presence of performance hints in core does not break the
compatibility : the *usage* of that hint can break the compatibility -
so as usual, user must know what that parameter means and what it can
cause.
1) I think JSF implementation can break the specified functionality:
myfaces did it already with elResolvers sorting for example. But the
default must be always false for 100% compatibility with JSF
specification.
2) The hint technique is very common : another example from Java EE is
world JPA Query.setHint
3) Hints are a simple way to realize something this should be in core
but because of slow specification release cycle, you must wait a year or
two to get it officially specified in public API.
4) Ease of usage: for example, if you have only one readonly table in
whole project, creation of custom component for that purpose is an
overkill: simple f:attribute name=oam.readOnly value=true / is
much easier.
5) Internet is full of JSF is slow. Although I know that is completely
untrue, hinting the core for more performance is a easy way which
allows users to express all they need without additional dependencies.
So, do you think we really can't put this feature in core? I mean the
hints feature generally, not readonly UIData - that was only an
example.
Regards,
Kočičák
Anyway, I think it is possible to do some work on UIData to make it
perform
faster and better.
Lifespan of those hints can be request
(faceContext.attributes) or view
(component.attributes)
I don't think in this case it applies, but any configuration param for
a view
should be on a tag like f:view or something similar.
regards,
Leonardo
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
Re: [core] performance: performance hints
I think it is time to propose a new axiom relating to boolean properties. I would name it after Blake, who first called this truth to my attention: Blake's Axiom of Boolean Properties: You will regret making your property a boolean. :-) In this particular case, I am thinking about the UIData rowStatePreserved boolean property that we added in JSF 2.1. This currently has two values: 1. true: UIData performs state saving (ideally partial state saving) to save away row-specific properties. 2. false: UIData uses the old hacky mechanism for saving row-specific state (special casing EditableValueHolders and what not). In retrospect, it sure would have been nice to allow for a third value: 3. none: Don't make any attempt at state saving. Though now that UIData is stuck with a boolean type for this property, we don't have a simple way to support #3 (for UIData) that doesn't involve adding yet another attribute. In any case, I think it is fine to support this optimization one way or another (eg. along the lines discussed above). Of course, the magical ideal solution would be to come up with some clever way to automatically pick the best behavior. Or, failing that, it might be good to warn developers when they specify potentially conflicting values (such as disabling state saving for tables that stamp EditableValueHolders.) Andy
Re: [core] performance: performance hints
heh, that reminds me of the quardrary logic of an old colleague: ja/nein/weißnicht/habangst (roughly translates to : yes/no/ihavenoidea/angst) :) LieGrue, strub --- On Tue, 4/26/11, Andy Schwartz andy.g.schwa...@gmail.com wrote: From: Andy Schwartz andy.g.schwa...@gmail.com Subject: Re: [core] performance: performance hints To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 26, 2011, 5:54 PM I think it is time to propose a new axiom relating to boolean properties. I would name it after Blake, who first called this truth to my attention: Blake's Axiom of Boolean Properties: You will regret making your property a boolean. :-) In this particular case, I am thinking about the UIData rowStatePreserved boolean property that we added in JSF 2.1. This currently has two values: 1. true: UIData performs state saving (ideally partial state saving) to save away row-specific properties. 2. false: UIData uses the old hacky mechanism for saving row-specific state (special casing EditableValueHolders and what not). In retrospect, it sure would have been nice to allow for a third value: 3. none: Don't make any attempt at state saving. Though now that UIData is stuck with a boolean type for this property, we don't have a simple way to support #3 (for UIData) that doesn't involve adding yet another attribute. In any case, I think it is fine to support this optimization one way or another (eg. along the lines discussed above). Of course, the magical ideal solution would be to come up with some clever way to automatically pick the best behavior. Or, failing that, it might be good to warn developers when they specify potentially conflicting values (such as disabling state saving for tables that stamp EditableValueHolders.) Andy
Re: [core] performance: performance hints
Hi
2011/4/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Unfortunately, we can't do anything like that on default UIData
implementation
(it could breaks backwards behavior). I think we could include a property
on tomahawk t:dataTable called readOnly, that just skip all that code
related to save/restore for rows. That could be better, and it has sense to
put in tomahawk, because after all that is the right location for extend
default jsf components.
Anyway, I think it is possible to do some work on UIData to make it perform
faster and better.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
I don't think in this case it applies, but any configuration param for a
view
should be on a tag like f:view or something similar.
regards,
Leonardo
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
Re: [core] performance: performance hints
I totally support this improvement +1.
On Mon, Apr 25, 2011 at 12:45 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
2011/4/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Unfortunately, we can't do anything like that on default UIData
implementation
(it could breaks backwards behavior). I think we could include a property
on tomahawk t:dataTable called readOnly, that just skip all that code
related to save/restore for rows. That could be better, and it has sense to
put in tomahawk, because after all that is the right location for extend
default jsf components.
Anyway, I think it is possible to do some work on UIData to make it perform
faster and better.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
I don't think in this case it applies, but any configuration param for a
view
should be on a tag like f:view or something similar.
regards,
Leonardo
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
--
Hazem Ahmed Saleh Ahmed
Author of (The Definitive Guide to Apache MyFaces and Facelets):
http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
http://www.amazon.com/-/e/B002M052KY
Visualize and share your social networks 2D and 3D:
http://www.mapmysocial.com
Re: [core] performance: performance hints
+1!
best regards,
Martin
On 4/20/11, Gerhard Petracek gerhard.petra...@gmail.com wrote:
+1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/4/20 Jakob Korherr jakob.korh...@gmail.com
Hi,
That's a great idea! Please do that :)
IMO there is still a lot of potential in the state saving area. I
think every idea for an improvement is appreciated here!
Regards,
Jakob
2011/4/19, Martin Koci martin.kocicak.k...@gmail.com:
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [core] performance: performance hints
Hi,
That's a great idea! Please do that :)
IMO there is still a lot of potential in the state saving area. I
think every idea for an improvement is appreciated here!
Regards,
Jakob
2011/4/19, Martin Koci martin.kocicak.k...@gmail.com:
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [core] performance: performance hints
+1
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/4/20 Jakob Korherr jakob.korh...@gmail.com
Hi,
That's a great idea! Please do that :)
IMO there is still a lot of potential in the state saving area. I
think every idea for an improvement is appreciated here!
Regards,
Jakob
2011/4/19, Martin Koci martin.kocicak.k...@gmail.com:
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
