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