Hi Matze, for 1 - look at this:
http://myfaces.apache.org/orchestra/myfaces-orchestra-core/component-bindings.html for 2 - there is nothing definitive there (JSF 2.0 has not yet been released), but that's my opinion which will probably proof to be true ;) regards, Martin On 10/24/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > are some docs on that out there ? > > On 10/24/07, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > 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 > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > mail: matzew-at-apache-dot-org > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
