Not really. I have always avoided both session scoped beans and component building via java code (except years ago before I discovered facelets).
I know others have done it. The only possibly-helpful tips I can remember are 1) do the component creation in the getter not the setter, and always manually set an id. The more I think about it, the more I think I'll try the c:forEach and c:if technique (with facelets) first. On 10/22/07, Michael Heinen <[EMAIL PROTECTED]> wrote: > 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 > > > > > >
