On Jan 30, 2008 9:39 PM, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > Hi! > > ok - then please suggest one. This is all about finding a clean way, > > and we are at this point as we haven't found another clean way to do > > it so far. > > > I had a quick chat about this topic with Matthias and I think now I > understood a little bit better what the thought how to work with the > generator stuff. > > The idea is (as everyone migh know) to generate the config files/taglibs > and (the discussed) component. Matthias said, that one normally does NOT > have to change this class as the real work has to be done in the renderer.
ahm, not sure what I really said, however, we have logic in the components. They are not! simple containers that have only get/set ...... Like this: (simple example for <tr:inputText>): Components. The comp is "CoreInputText" (generated and fairly simple (get/set). This extends "UIXInput". UIXInput is a base class for all "input" components (like inputText or inputFile). Simple as well (and generated). deals with family and setting renderType in the constructor. The "UIXInput" extends the "UIXEditableValue". UIXEditableValue is a bit more "complex" does things like: -validate() -resetValue() -processValidators() -broadcast() -... all this is "logic" and it is defined in the *template* for the UIXEditableValue class (UIXEditableValueTemplate.java) Now this class extends "UIXValue". This one is simple, but still there is a template (UIXValueTemplate.java) to add things (if needed) This class extends "UIXComponentBase". This class is part of the SVN (ergo real source), because the "mother" (base implementation) of all Trinidad components. UIXComponentBase extends "UIXComponent". UIXComponent is an abstract class that extends "javax.faces.component.UIComponent". now the Renderer (which is, for rendering). they read the properties and render them out. Not sure, but perhaps that makes it a little bit more clear. Please note (not to get more confusion into the "crazy" thread), that this is "just" a "simplified" example. -M > I am not fully convinced about that, but have to admit that I am not a > full-blown-component developer - just some small pieces now and then. > > I told him that I think the component logic should live within the > component - where he didnt disagree, but also pointed me to the fact > that one can always have a abstract base renderer where the common code > might live. I think that this not fully in sync with the component idea, > but might work. > > In the end, it seems as if you could create 95% of all components > without having to touch the generated class - as long as you just work > with the renderer classes. > Which means, no need for generating an abstract basis class. > > I am not sure if I like this "standard", but wanted to write this as I > think it helps to understand what the idea was/is behind all this. > > Sorry Matthias if I made some mistake in the summarize and probably > misinterpreted one detail or another. But I think overall it is correct. > > Ciao, > Mario > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
