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.


>
> >
> >
> >         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
> >
>
>

Reply via email to