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