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? Regards, Simon >
