Hi Mike, Michael, you should not use component-bindings with session-scoped beans - if you take a look at Orchestra, you can however find a way how to embed a request-scoped bean into a session-scoped bean, and put your component-bindings there.
Looking forward to JSF 2.0, I would not use component bindings if you can help it. In JSF 2.0, much of the state will be stored in the template, not in the component-tree - so you will have better performance if you keep to the template as much as possible. regards, Martin On 10/22/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
