You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Koci <ma...@gmail.com> on 2011/04/19 20:34:45 UTC
[core] performance: performance hints
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.
Re: [core] performance: performance hints
Posted by Martin Marinschek <mm...@apache.org>.
+1!
best regards,
Martin
On 4/20/11, Gerhard Petracek <ge...@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 <ja...@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 <ma...@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
Posted by Gerhard Petracek <ge...@gmail.com>.
+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 <ja...@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 <ma...@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
Posted by Jakob Korherr <ja...@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 <ma...@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
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi Bernd
Yes, I can backport them to 1.2.x. I was waiting if someone was
interested on, but that was fast!
regards,
Leonardo
2011/7/22 Bernd Bohmann <be...@atanion.com>:
> Hello Leonardo,
>
> can we backport this code to 1.2.x?
>
> Regards
>
> Bernd
>
> On Fri, Jul 22, 2011 at 11:10 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>> Hi
>>
>> Just for your informatino, I did some really big improvements over the
>> algorithm, making unnecessary add this hint. See:
>>
>> https://issues.apache.org/jira/browse/MYFACES-3236
>>
>> for details. This was commited on 2.0.x and 2.1.x branch. It could be
>> good if someone can do some performance tests over this one.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/4/28 Leonardo Uribe <lu...@gmail.com>:
>>> Hi
>>>
>>> Ok, I'll do a resume about the discussion and provide some opinions
>>> about that.
>>>
>>> LU >>>>That could be better, and it has sense to put in tomahawk,
>>> LU >>>> because after all that is the right location for extend
>>> LU >>>> default jsf components.
>>>
>>> MK >> Yes, this is one point of view and I agree with that "custom behaviour
>>> MK >> belongs into custom component". I did exactly the same for my
>>> component.
>>>
>>> MK >> But there are other topics to consider:
>>>
>>> MK >> 0) simple presence of performance hints in core does not break the
>>> MK >> compatibility : the *usage* of that hint can break the compatibility -
>>> MK >>so as usual, user must know what that parameter means and what it can
>>> MK >> cause.
>>>
>>> Yes, the important thing to note is this could not be the default behavior.
>>>
>>> MK >> 1) I think JSF implementation can break the specified functionality:
>>> MK >> myfaces did it already with elResolvers sorting for example. But the
>>> MK >> default must be always false for 100% compatibility with JSF
>>> MK >> specification.
>>>
>>> Yes, note the default algorithm provide the elResolvers in the expected
>>> order as
>>> the spec says.
>>>
>>> MK >> 2) The hint technique is very common : another example from Java EE is
>>> MK >> world JPA Query.setHint
>>>
>>> Good example.
>>>
>>> MK >> 3) Hints are a simple way to realize something "this should be in
>>> core"
>>> MK >> but because of slow specification release cycle, you must wait a year
>>> or
>>> MK >> two to get it officially specified in public API.
>>>
>>> Agreed
>>>
>>> MK >> 4) Ease of usage: for example, if you have only one readonly table in
>>> MK >> whole project, creation of custom component for that purpose is an
>>> MK >> overkill: simple <f:attribute name="oam.readOnly" value="true" /> is
>>> MK >> much easier.
>>>
>>> Good idea. I like the proposal of use an attribute like "oam.readOnly",
>>> because
>>> users can see quickly this attribute is MyFaces specific. But note an
>>> interesting
>>> point, in facelets mode, use f:attribute is not necessary because there
>>> exists
>>> a MethodRule called org.apache.myfaces.view.facelets.tag.jsf.ComponentRule
>>> that is added by default to all component tags and automatically wire all
>>> attributes
>>> to the attribute map. So this could be valid too:
>>>
>>> <h:dataTable oam.readOnly="true" ... >
>>>
>>> Note internally, the value assigned to this property will be a String, not a
>>> boolean,
>>> because f:attribute or ComponentRule can't do type conversion in this case.
>>>
>>> MK >> 5) Internet is full of "JSF is slow". Although I know that is
>>> completely
>>> MK >> untrue, "hinting the core" for more performance is a easy way which
>>> MK >> allows users to express all they need without additional dependencies.
>>>
>>> Agreed.
>>>
>>> MK >> So, do you think we really can't put this feature in core? I mean the
>>> MK >> "hints feature" generally, not readonly UIData - that was only an
>>> MK >> example.
>>>
>>> Based on the latest information I think it is ok to add it, as long as we
>>> use a
>>> distinctive name (like oam.readOnly) to indicate the attribute is myfaces
>>> specific.
>>> Note this new attribute should be included on MyFaces generated facelets tld
>>> javadoc.
>>>
>>> AS >> Blake's Axiom of Boolean Properties: You will regret making your
>>> AS >> property a boolean.
>>>
>>> :-) Really it is not a big deal, but good point.
>>>
>>> Really my opinion is it is possible for UIData to perform better without
>>> introduce
>>> this hint, and we should aim for that first. It could be good if UIData
>>> knows that
>>> there are no EditableValueHolder instances on the component tree, just skip
>>> state saving automatically (in fact that code will only be executed just
>>> once per
>>> request).
>>>
>>> AS >> Though now that UIData is stuck with a boolean type for this property,
>>> AS >> we don't have a simple way to support #3 (for UIData) that doesn't
>>> AS >> involve adding yet another attribute.
>>>
>>> AS >> In any case, I think it is fine to support this optimization one way
>>> AS >> or another (eg. along the lines discussed above).
>>>
>>> AS >> Of course, the magical ideal solution would be to come up with some
>>> AS >> clever way to automatically pick the best behavior. Or, failing that,
>>> AS >> it might be good to warn developers when they specify potentially
>>> AS >> conflicting values (such as disabling state saving for tables that
>>> AS >> stamp EditableValueHolders.)
>>>
>>> I was thinking on put some code in JSF 2.1 for UData.markInitialState, that
>>> check if there is EditableValueHolder instances on the row, and if no
>>> instance is
>>> found, make UIData skip automatically state saving code.
>>>
>>> Suggestions are welcome
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/4/27 Jakob Korherr <ja...@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 <st...@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 <an...@gmail.com> wrote:
>>>> >
>>>> >> From: Andy Schwartz <an...@gmail.com>
>>>> >> Subject: Re: [core] performance: performance hints
>>>> >> To: "MyFaces Development" <de...@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
Posted by Bernd Bohmann <be...@atanion.com>.
Hello Leonardo,
can we backport this code to 1.2.x?
Regards
Bernd
On Fri, Jul 22, 2011 at 11:10 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> Just for your informatino, I did some really big improvements over the
> algorithm, making unnecessary add this hint. See:
>
> https://issues.apache.org/jira/browse/MYFACES-3236
>
> for details. This was commited on 2.0.x and 2.1.x branch. It could be
> good if someone can do some performance tests over this one.
>
> regards,
>
> Leonardo Uribe
>
> 2011/4/28 Leonardo Uribe <lu...@gmail.com>:
>> Hi
>>
>> Ok, I'll do a resume about the discussion and provide some opinions
>> about that.
>>
>> LU >>>>That could be better, and it has sense to put in tomahawk,
>> LU >>>> because after all that is the right location for extend
>> LU >>>> default jsf components.
>>
>> MK >> Yes, this is one point of view and I agree with that "custom behaviour
>> MK >> belongs into custom component". I did exactly the same for my
>> component.
>>
>> MK >> But there are other topics to consider:
>>
>> MK >> 0) simple presence of performance hints in core does not break the
>> MK >> compatibility : the *usage* of that hint can break the compatibility -
>> MK >>so as usual, user must know what that parameter means and what it can
>> MK >> cause.
>>
>> Yes, the important thing to note is this could not be the default behavior.
>>
>> MK >> 1) I think JSF implementation can break the specified functionality:
>> MK >> myfaces did it already with elResolvers sorting for example. But the
>> MK >> default must be always false for 100% compatibility with JSF
>> MK >> specification.
>>
>> Yes, note the default algorithm provide the elResolvers in the expected
>> order as
>> the spec says.
>>
>> MK >> 2) The hint technique is very common : another example from Java EE is
>> MK >> world JPA Query.setHint
>>
>> Good example.
>>
>> MK >> 3) Hints are a simple way to realize something "this should be in
>> core"
>> MK >> but because of slow specification release cycle, you must wait a year
>> or
>> MK >> two to get it officially specified in public API.
>>
>> Agreed
>>
>> MK >> 4) Ease of usage: for example, if you have only one readonly table in
>> MK >> whole project, creation of custom component for that purpose is an
>> MK >> overkill: simple <f:attribute name="oam.readOnly" value="true" /> is
>> MK >> much easier.
>>
>> Good idea. I like the proposal of use an attribute like "oam.readOnly",
>> because
>> users can see quickly this attribute is MyFaces specific. But note an
>> interesting
>> point, in facelets mode, use f:attribute is not necessary because there
>> exists
>> a MethodRule called org.apache.myfaces.view.facelets.tag.jsf.ComponentRule
>> that is added by default to all component tags and automatically wire all
>> attributes
>> to the attribute map. So this could be valid too:
>>
>> <h:dataTable oam.readOnly="true" ... >
>>
>> Note internally, the value assigned to this property will be a String, not a
>> boolean,
>> because f:attribute or ComponentRule can't do type conversion in this case.
>>
>> MK >> 5) Internet is full of "JSF is slow". Although I know that is
>> completely
>> MK >> untrue, "hinting the core" for more performance is a easy way which
>> MK >> allows users to express all they need without additional dependencies.
>>
>> Agreed.
>>
>> MK >> So, do you think we really can't put this feature in core? I mean the
>> MK >> "hints feature" generally, not readonly UIData - that was only an
>> MK >> example.
>>
>> Based on the latest information I think it is ok to add it, as long as we
>> use a
>> distinctive name (like oam.readOnly) to indicate the attribute is myfaces
>> specific.
>> Note this new attribute should be included on MyFaces generated facelets tld
>> javadoc.
>>
>> AS >> Blake's Axiom of Boolean Properties: You will regret making your
>> AS >> property a boolean.
>>
>> :-) Really it is not a big deal, but good point.
>>
>> Really my opinion is it is possible for UIData to perform better without
>> introduce
>> this hint, and we should aim for that first. It could be good if UIData
>> knows that
>> there are no EditableValueHolder instances on the component tree, just skip
>> state saving automatically (in fact that code will only be executed just
>> once per
>> request).
>>
>> AS >> Though now that UIData is stuck with a boolean type for this property,
>> AS >> we don't have a simple way to support #3 (for UIData) that doesn't
>> AS >> involve adding yet another attribute.
>>
>> AS >> In any case, I think it is fine to support this optimization one way
>> AS >> or another (eg. along the lines discussed above).
>>
>> AS >> Of course, the magical ideal solution would be to come up with some
>> AS >> clever way to automatically pick the best behavior. Or, failing that,
>> AS >> it might be good to warn developers when they specify potentially
>> AS >> conflicting values (such as disabling state saving for tables that
>> AS >> stamp EditableValueHolders.)
>>
>> I was thinking on put some code in JSF 2.1 for UData.markInitialState, that
>> check if there is EditableValueHolder instances on the row, and if no
>> instance is
>> found, make UIData skip automatically state saving code.
>>
>> Suggestions are welcome
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/4/27 Jakob Korherr <ja...@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 <st...@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 <an...@gmail.com> wrote:
>>> >
>>> >> From: Andy Schwartz <an...@gmail.com>
>>> >> Subject: Re: [core] performance: performance hints
>>> >> To: "MyFaces Development" <de...@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
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Just for your informatino, I did some really big improvements over the
algorithm, making unnecessary add this hint. See:
https://issues.apache.org/jira/browse/MYFACES-3236
for details. This was commited on 2.0.x and 2.1.x branch. It could be
good if someone can do some performance tests over this one.
regards,
Leonardo Uribe
2011/4/28 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> Ok, I'll do a resume about the discussion and provide some opinions
> about that.
>
> LU >>>>That could be better, and it has sense to put in tomahawk,
> LU >>>> because after all that is the right location for extend
> LU >>>> default jsf components.
>
> MK >> Yes, this is one point of view and I agree with that "custom behaviour
> MK >> belongs into custom component". I did exactly the same for my
> component.
>
> MK >> But there are other topics to consider:
>
> MK >> 0) simple presence of performance hints in core does not break the
> MK >> compatibility : the *usage* of that hint can break the compatibility -
> MK >>so as usual, user must know what that parameter means and what it can
> MK >> cause.
>
> Yes, the important thing to note is this could not be the default behavior.
>
> MK >> 1) I think JSF implementation can break the specified functionality:
> MK >> myfaces did it already with elResolvers sorting for example. But the
> MK >> default must be always false for 100% compatibility with JSF
> MK >> specification.
>
> Yes, note the default algorithm provide the elResolvers in the expected
> order as
> the spec says.
>
> MK >> 2) The hint technique is very common : another example from Java EE is
> MK >> world JPA Query.setHint
>
> Good example.
>
> MK >> 3) Hints are a simple way to realize something "this should be in
> core"
> MK >> but because of slow specification release cycle, you must wait a year
> or
> MK >> two to get it officially specified in public API.
>
> Agreed
>
> MK >> 4) Ease of usage: for example, if you have only one readonly table in
> MK >> whole project, creation of custom component for that purpose is an
> MK >> overkill: simple <f:attribute name="oam.readOnly" value="true" /> is
> MK >> much easier.
>
> Good idea. I like the proposal of use an attribute like "oam.readOnly",
> because
> users can see quickly this attribute is MyFaces specific. But note an
> interesting
> point, in facelets mode, use f:attribute is not necessary because there
> exists
> a MethodRule called org.apache.myfaces.view.facelets.tag.jsf.ComponentRule
> that is added by default to all component tags and automatically wire all
> attributes
> to the attribute map. So this could be valid too:
>
> <h:dataTable oam.readOnly="true" ... >
>
> Note internally, the value assigned to this property will be a String, not a
> boolean,
> because f:attribute or ComponentRule can't do type conversion in this case.
>
> MK >> 5) Internet is full of "JSF is slow". Although I know that is
> completely
> MK >> untrue, "hinting the core" for more performance is a easy way which
> MK >> allows users to express all they need without additional dependencies.
>
> Agreed.
>
> MK >> So, do you think we really can't put this feature in core? I mean the
> MK >> "hints feature" generally, not readonly UIData - that was only an
> MK >> example.
>
> Based on the latest information I think it is ok to add it, as long as we
> use a
> distinctive name (like oam.readOnly) to indicate the attribute is myfaces
> specific.
> Note this new attribute should be included on MyFaces generated facelets tld
> javadoc.
>
> AS >> Blake's Axiom of Boolean Properties: You will regret making your
> AS >> property a boolean.
>
> :-) Really it is not a big deal, but good point.
>
> Really my opinion is it is possible for UIData to perform better without
> introduce
> this hint, and we should aim for that first. It could be good if UIData
> knows that
> there are no EditableValueHolder instances on the component tree, just skip
> state saving automatically (in fact that code will only be executed just
> once per
> request).
>
> AS >> Though now that UIData is stuck with a boolean type for this property,
> AS >> we don't have a simple way to support #3 (for UIData) that doesn't
> AS >> involve adding yet another attribute.
>
> AS >> In any case, I think it is fine to support this optimization one way
> AS >> or another (eg. along the lines discussed above).
>
> AS >> Of course, the magical ideal solution would be to come up with some
> AS >> clever way to automatically pick the best behavior. Or, failing that,
> AS >> it might be good to warn developers when they specify potentially
> AS >> conflicting values (such as disabling state saving for tables that
> AS >> stamp EditableValueHolders.)
>
> I was thinking on put some code in JSF 2.1 for UData.markInitialState, that
> check if there is EditableValueHolder instances on the row, and if no
> instance is
> found, make UIData skip automatically state saving code.
>
> Suggestions are welcome
>
> regards,
>
> Leonardo Uribe
>
> 2011/4/27 Jakob Korherr <ja...@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 <st...@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 <an...@gmail.com> wrote:
>> >
>> >> From: Andy Schwartz <an...@gmail.com>
>> >> Subject: Re: [core] performance: performance hints
>> >> To: "MyFaces Development" <de...@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
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Ok, I'll do a resume about the discussion and provide some opinions
about that.
LU >>>>That could be better, and it has sense to put in tomahawk,
LU >>>> because after all that is the right location for extend
LU >>>> default jsf components.
MK >> Yes, this is one point of view and I agree with that "custom behaviour
MK >> belongs into custom component". I did exactly the same for my
component.
MK >> But there are other topics to consider:
MK >> 0) simple presence of performance hints in core does not break the
MK >> compatibility : the *usage* of that hint can break the compatibility -
MK >>so as usual, user must know what that parameter means and what it can
MK >> cause.
Yes, the important thing to note is this could not be the default behavior.
MK >> 1) I think JSF implementation can break the specified functionality:
MK >> myfaces did it already with elResolvers sorting for example. But the
MK >> default must be always false for 100% compatibility with JSF
MK >> specification.
Yes, note the default algorithm provide the elResolvers in the expected
order as
the spec says.
MK >> 2) The hint technique is very common : another example from Java EE is
MK >> world JPA Query.setHint
Good example.
MK >> 3) Hints are a simple way to realize something "this should be in
core"
MK >> but because of slow specification release cycle, you must wait a year
or
MK >> two to get it officially specified in public API.
Agreed
MK >> 4) Ease of usage: for example, if you have only one readonly table in
MK >> whole project, creation of custom component for that purpose is an
MK >> overkill: simple <f:attribute name="oam.readOnly" value="true" /> is
MK >> much easier.
Good idea. I like the proposal of use an attribute like "oam.readOnly",
because
users can see quickly this attribute is MyFaces specific. But note an
interesting
point, in facelets mode, use f:attribute is not necessary because there
exists
a MethodRule called org.apache.myfaces.view.facelets.tag.jsf.ComponentRule
that is added by default to all component tags and automatically wire all
attributes
to the attribute map. So this could be valid too:
<h:dataTable oam.readOnly="true" ... >
Note internally, the value assigned to this property will be a String, not a
boolean,
because f:attribute or ComponentRule can't do type conversion in this case.
MK >> 5) Internet is full of "JSF is slow". Although I know that is
completely
MK >> untrue, "hinting the core" for more performance is a easy way which
MK >> allows users to express all they need without additional dependencies.
Agreed.
MK >> So, do you think we really can't put this feature in core? I mean the
MK >> "hints feature" generally, not readonly UIData - that was only an
MK >> example.
Based on the latest information I think it is ok to add it, as long as we
use a
distinctive name (like oam.readOnly) to indicate the attribute is myfaces
specific.
Note this new attribute should be included on MyFaces generated facelets tld
javadoc.
AS >> Blake's Axiom of Boolean Properties: You will regret making your
AS >> property a boolean.
:-) Really it is not a big deal, but good point.
Really my opinion is it is possible for UIData to perform better without
introduce
this hint, and we should aim for that first. It could be good if UIData
knows that
there are no EditableValueHolder instances on the component tree, just skip
state saving automatically (in fact that code will only be executed just
once per
request).
AS >> Though now that UIData is stuck with a boolean type for this property,
AS >> we don't have a simple way to support #3 (for UIData) that doesn't
AS >> involve adding yet another attribute.
AS >> In any case, I think it is fine to support this optimization one way
AS >> or another (eg. along the lines discussed above).
AS >> Of course, the magical ideal solution would be to come up with some
AS >> clever way to automatically pick the best behavior. Or, failing that,
AS >> it might be good to warn developers when they specify potentially
AS >> conflicting values (such as disabling state saving for tables that
AS >> stamp EditableValueHolders.)
I was thinking on put some code in JSF 2.1 for UData.markInitialState, that
check if there is EditableValueHolder instances on the row, and if no
instance is
found, make UIData skip automatically state saving code.
Suggestions are welcome
regards,
Leonardo Uribe
2011/4/27 Jakob Korherr <ja...@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 <st...@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 <an...@gmail.com> wrote:
> >
> >> From: Andy Schwartz <an...@gmail.com>
> >> Subject: Re: [core] performance: performance hints
> >> To: "MyFaces Development" <de...@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
Posted by Jakob Korherr <ja...@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 <st...@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 <an...@gmail.com> wrote:
>
>> From: Andy Schwartz <an...@gmail.com>
>> Subject: Re: [core] performance: performance hints
>> To: "MyFaces Development" <de...@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
Posted by Mark Struberg <st...@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 <an...@gmail.com> wrote:
> From: Andy Schwartz <an...@gmail.com>
> Subject: Re: [core] performance: performance hints
> To: "MyFaces Development" <de...@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
Posted by Andy Schwartz <an...@gmail.com>.
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
Posted by Bernd Bohmann <be...@atanion.com>.
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
<ma...@gmail.com> wrote:
> Hi,
>
> Leonardo Uribe píše v Po 25. 04. 2011 v 12:45 +0200:
>> Hi
>>
>> 2011/4/19 Martin Koci <ma...@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
Posted by Martin Koci <ma...@gmail.com>.
Hi,
Leonardo Uribe píše v Po 25. 04. 2011 v 12:45 +0200:
> Hi
>
> 2011/4/19 Martin Koci <ma...@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
Posted by Hazem Saleh <ha...@apache.org>.
I totally support this improvement +1.
On Mon, Apr 25, 2011 at 12:45 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> 2011/4/19 Martin Koci <ma...@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
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2011/4/19 Martin Koci <ma...@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.
>
>