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 >
