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 >
