On Sat, 2008-06-21 at 22:39 +0200, simon wrote: > On Sat, 2008-06-21 at 15:06 -0500, Leonardo Uribe wrote: > > > > > > On Sat, Jun 21, 2008 at 2:37 PM, simon <[EMAIL PROTECTED]> > > wrote: > > > > On Sat, 2008-06-21 at 14:22 -0500, Leonardo Uribe wrote: > > > > > > > > Because myfaces-api define tag classes which > > subclasses should > > > inherit. > > > > > > For example, t:commandButton extends from > > h:commandButton. But > > > h:commandButton has > > > its own tag class, so the tag class of > > t:commandButton inherit > > > from h:commandButton tag class. > > > > > > Theorically, it is possible to generate a tag class > > that > > > always extends from UIComponentTag or > > > UIComponentELTag, without taking into account the > > tag > > > hierarchy (the difference really could > > > be on the template). But I like the inheritance of > > tag > > > classes, specially when you need some > > > hack like in s:inputSuggestAjax. > > > > > > > > > I forget to say that the tag classes on shared project are > > now useless > > > (right now there is no project using it!). > > > All tag classes right now are generated. > > > > > > So as I understand it, the problem is that in the original > > tomahawk > > code, there is a tag class that handles all of the UIColumn > > properties > > (defines setters and getters, and is able to pass them on to > > the target > > UIComponent). And tomahawk components which extend UIComponent > > are > > annotated to specify this class as the base for their own > > tags. > > > > The tomahawk components cannot be annotated to extend the > > class > > o.a.myfaces.*.UIColumnTag because then tomahawk would not work > > with > > mojarra. So we need an identical copy of this tag class in a > > different > > package in order to run with different JSF implementations. > > > > I have to say, I don't like the current "repackage" solution. > > It's just > > too confusing (to me at least). > > > > Option (1) would be to just do without a base UIColumnTag > > class. > > Instead, have tag classes always extend just the public base > > classes > > from the JSF api, ie UIComponentTagBase and similar. Ok, there > > will be > > code duplication. But it's all trivial code, and all > > automatically > > generated. > > > > Option (2) would be to support tagClass annotations on > > abstract > > UIComponent classes. A matching abstract tag class would be > > created > > (sounds logical). Then in tomahawk we would just need to > > declare an > > abstract class that extends UIColumn, and specifies a tagClass > > name. The > > disadvantage is that this abstract component class would > > probably not be > > used for anything else - unless we change the existing classes > > that > > subclass the javax UIColumn to instead subclass this abstract > > one (which > > *would* be elegant). But it would be a trivial class. And the > > advantage > > is that this approach is entirely consistent with the rest of > > the > > builder plugin. > > > > Option (2) looks quite good to me. What do you think? > > > > > > Right now, the actual approach seems to be the most effective (this > > problem was a > > really BIG headache when I did component generation with > > myfaces-faces-plugin, it > > takes me many weeks to understand it). I'm open mind to all > > suggestions, but this > > part is very, very critical for correct working of tomahawk. > > > > The problem with this approach is how inheritTag param of > > PropertyMeta works. If you > > create an abstract class that extends from HtmlCommandButton for > > example with another > > tag class and superclass (annotated), you have to set manually all > > properties with inheritTag = false, > > to be generated on the tag class (very awful). > > = > > Hmm. That inheritTag stuff on PropertyMeta is also rather confusing. > > >From JSFProperty.java: > /** > * Indicate if this property is inherited from a parent tag class or not. > */ > boolean inheritTag() default false; > > What does this mean? Components don't inherit properties from tags... > > > Is this something to do with handling situations like this (<= indicates > inheritance): > CompA <= CompB <= CompC > tagA <= tagC > where component B is abstract, and so has no tag class? So it is > necessary to figure out what setters/getters tagC needs to define? > > Or is it something else?
Having looked at the code, it seems like my guess above was right. It's all about figuring out which setter methods to write onto a tag class. The tag class has to handle all the properties of the associated component, but can skip those that are already handled by the parent tag class. This data is easily available in the non-flattened model, but having flattened everything we now have lost track of what fields belonged to what. So the inheritedTag field now marks what fields were inherited, so we know what to exclude. Actually, it doesn't just mark what is inherited, but rather what was inherited since the last time a parent component actually specified a tag class. I guess that's reasonable, although a little more documentation would have helped. But I'm really puzzled why there is annotation support for setting this directly. When would a class want to explicitly control this? As always, I feel uncomfortable with using the word "tag". It always sets off alarm bells because it suggests we are modelling the solution and not the problem domain. An alternative would be to do this a little more directly: leave out the inheritedTag flags, and simply compute the properties via: * find CompX associated with the tag parent class TagX * get the set of properties for the current component Y * subtract the properties of X * the remainder is the list to output for TagY I'll think some more about this. Regards, Simon
