Regarding your approach with the component bindings: I have not used them at all and I am a little bit afraid of them. In this list I read multiple times that they are some kind of "evil" ;-) specially in combination with session scoped beans.
Btw I don't like my approach with the rendered flags but this allows the html designers to do easy modifications which they can't do if I set everything programmatically in components. But the component binding approach should be more performant of course. Do you have any good tips regarding component bindings in combination with session scoped beans ? Michael -----Original Message----- From: Mike Kienenberger [mailto:[EMAIL PROTECTED] Sent: Montag, 22. Oktober 2007 17:47 To: MyFaces Discussion Subject: Re: optional validator - missing rendered attribute For what it's worth, the optional validation discussions of the past dealt with wrapping each validator in an "optional validator" component, and then globally traversing the component tree. This approach works very poorly, so I abandoned it in favor of s:subForm. That will not help your situation, however. All of the tomahawk validators inherit from ValidatorBase. You could add an optional attribute to that class, but you'd still have to change each validator to evaluate it. This also won't help for the non-ValidatorBase validators. I will probably be in a similar situation down the road. I suspect that the "easiest" solution will be to bind a component (like a panelGroup) to a backing bean and dynamically construct the dynamic component tree from java code rather than trying to do it from page code with rendered (and active) attributes. Although with facelets, using c:forEach and c:if might work too. On 10/22/07, Michael Heinen <[EMAIL PROTECTED]> wrote: > Hi Simon, > > maybe I did not express myself or the problem well. > I didn't want to go on confrontation course, sorry if you got that impression. > Quite the contrary I am happy about feedback, workarounds and suggestions. That's the reason for my postings. > > I just was astonished that all components have the rendered attribute but validators not. > Now I know that there is not any existing feature that I missed and use various input components with their own validators. > > But a disadvantage of this is from my point of view that I have also to use multiple label tags (or EL expressions for the for-attribute because I have then various input fields with other client ids used in the for-attribute of the label tag). > And ajax updates will be a little bit more complex because I have to update a container tag rather than directly a field. > > Michael > > > -----Original Message----- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Montag, 22. Oktober 2007 16:08 > To: MyFaces Discussion > Cc: Michael Heinen > Subject: RE: optional validator - missing rendered attribute > > Hi Michael, > > ---- Michael Heinen <[EMAIL PROTECTED]> schrieb: > > Here is a sample: > > > > <t:dataList id="myFields" > > value="#{FieldConfigurationController.myFields}" > > var="entry"> > > <t:div rendered="#{entry.type=='inputText'}"> > > <t:inputText id="s_inputText" > > value="#{MyController.search.attributes[entry.name]}" > > ... > > > <my:validateCompareTo active="#{entry.contentType=='range' && entry.name='to'}" > > for="rangeFrom" > > operator=">=" > > .../> > > <my:validateEmail active="#{entry.contentType=='email'}" ...> > > </t:inputText> > > ... > > </t:div> > > <t:div rendered="#{entry.type=='selectOne'}"> > > ... > > </t:div> > > <t:dataList> > > > > I loop over a list which contains the fields that should be rendered. > > These fields are not known at compile time. The fields are created dynamically based on a database or other repositories. > > The model is also completely dynamic. It is represented by maps and accessed by field names. > > > > The above my:validateCompareTo should only be attached to fields of contentType range and should validate the upper against with the lower value. > > (e.g. see http://myfaces.apache.org/sandbox/validateCompareTo.html > > This validator is attached to the bottom-most component to insure that the foreign component's value has been converted and validated first) > > > > my:validateEmail should be attached to fields of contentType email only. > > > > I don't want to use multiple input fields if they are rendered all the same way. > > Do you now see the difficulty ? > > Yes, I see. > > However I think this is a fairly unusual situation. I don't believe that handling validation for such dynamically-created and dynamically-typed input components really qualifies as "a common use-case". > > However can't this be solved simply by moving the input component inside the type-test? IE rather than: > for each field to render > add an inputText, always rendered > attach validator1, active if type=1 > attach validator2, active if type=2 > do: > for each field to render > add inputText rendered if type=1, with validator1 > add inputText rendered if type=2, with validator2 > > Yes, this does mean repeating the input-component for each type. But that gives the opportunity to change the actual input component type based on what the field-type is. Ok, *you* might happen to always want an input-text for all types, but I think this is a more general solution, and not too inconvenient in your case. > > In terms of memory usage and performance, the above are about equal. Either one component exists, with N validators (N+1 objects), or N components exist each with 1 validator (2N objects). Given that N is fairly small, this isn't significant IMO. > > That doesn't mean there is anything wrong with your "active" solution, but I don't personally see any need to amend the spec to support this use-case when it is (a) pretty rare, and (b) already has a reasonable solution. That's just my view of course. > > By the way, open-source projects are always happy to get suggestions/feedback (or should be); it's how projects get better. However when posting a message, please take care not to imply that the people in charge of the projects are fools for not solving the problem the way you think it should be solved. This email thread was perhaps a bit more confrontational than necessary.. > > Regards, > > Simon > >
