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). > > > > > (temporary) exception rather than the normal practice. > > Why does > > myfaces-api need "special hacks" that aren't in the > > normal processing? > > > > renderer type are defined on parent class. Really I did this > > for avoid changes on > > generated classes, and theorically the tomahawk template could > > be used for > > generate myfaces classes (I'm not tested it yet or put too > > much attention on this > > issue). > > Ok, I'll have a look at that and see how complicated it would be. It > sure would be nice to have a standard template, so that people only need > to read one file to understand how components are normally generated, > instead of having to read/understand the template file for each project. > > > > > > > What do you mean by "want the archetype for custom > > plugins"? > > > > archetype for create custom components using > > myfaces-builder-plugin. > > > So the archetype plugin automatically copies the template into the > directory tree it creates? > No, the archetype is just an idea for be implemented after tomahawk release, and the plugin doesn't do this right now. > > Regards, > Simon > > > > >
