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
