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