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 <bernd.bohm...@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 <lu4...@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 <lu4...@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 <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 >>> >>> >> >
