On Sat, Jun 21, 2008 at 2:09 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
> > > On Sat, Jun 21, 2008 at 1:51 PM, simon <[EMAIL PROTECTED]> wrote: > >> >> On Sat, 2008-06-21 at 10:51 -0500, Leonardo Uribe wrote: >> >> > >> > >> > What are these properties used for? >> > * replacePackagePrefixTagFrom >> > * replacePackagePrefixTagTo >> > >> > >> > On tomahawk, this properties are necessary on this execution: >> > >> > <execution> >> > <!-- A hierarchy of different tag classes must be >> > created, >> > because this classes are not part of the public api. The >> > generation of all html package is the same. Please note >> > that >> > we need only a subset --> >> > <configuration> >> > >> > >> <replacePackagePrefixTagFrom>org.apache.myfaces.taglib</replacePackagePrefixTagFrom> >> > >> > >> <replacePackagePrefixTagTo>org.apache.myfaces.shared_tomahawk.taglib</replacePackagePrefixTagTo> >> > </configuration> >> > <goals> >> > <goal>build-metadata</goal> >> > </goals> >> > </execution> >> > >> > The utility of this properties is generate all necessary base tag >> > classes which tomahawk components inherits, based >> > on the metadata of myfaces-api. For do that, it is necessary to tell >> > the builder plugin during the >> > build of its metadata, that replace the package name from: >> > >> > org.apache.myfaces.taglib >> > >> > to >> > >> > org.apache.myfaces.shared_tomahawk.taglib >> > >> > in order to avoid duplicate class exceptions when executing tomahawk >> > and myfaces core together. >> > I tried several hacks to do this and this hack probed to be the most >> > easy to understand and implements. >> > But maybe is not the only one. Suggestions are welcome!!!! >> >> I've read this over and over, and still don't have a clue what this >> means. Can you explain further? >> >> The only "base" classes for tags in the api project are: >> * UIComponentBodyTag >> * UIComponentTag >> and anyone can extend them. >> >> The following exist in the shared project: >> * UIComponentBodyTagBase >> and again, anyone can extend them. >> >> Metadata doesn't apply to these in any way. They aren't annotated, they >> are just normal classes that generated tags might extend. >> >> If there are any annotated components in tomahawk, then doesn't that >> just create its own tag classes (which might extend base classes defined >> in myfaces-impl or myfaces-shared)? Where does meta-data or duplicate >> classes come into this? >> > > 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. > >> > >> > >> > Why does each project need to define the templates itself? It >> > is getting >> > rather annoying (and error-prone) to keep them all >> > synchronized. I can >> > understand having the *option* to override the template, but >> > would it be >> > ok if it defaulted to using a template from the >> > myfaces-builder-plugin, >> > or is there a good reason not to? >> > >> > The problem is what happen if a error occur on the template and a fix >> > is needed. It is more easy to >> > modify a file inside the project that has the error that run a full >> > release of the plugin (in this >> > case myfaces-builder-plugin). >> > >> > Theorically, the default templates for everything should be tomahawk >> > templates (myfaces templates has >> > some special hacks and I want the archetype for custom plugins). But >> > for now I'm using a diff tool to move >> > changes and keep all of them synchronized. (myfaces core, tomhahawk, >> > sandbox and myfaces commons). >> > >> > The plugin is very intelligent in this case. First it try to found the >> > template on the project, then >> > on the classpath of the plugin. >> >> Ok, nice to know that it does fall back to the templates in the plugin. >> I'll try to find the code that does that.. >> >> But I think it would be much nicer if a private copy of a template was a >> (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). > > >> >> What do you mean by "want the archetype for custom plugins"? >> > > archetype for create custom components using myfaces-builder-plugin. > > >> Regards, >> Simon >> > >> >> >
