On Sat, 2008-05-31 at 16:26 -0500, Leonardo Uribe wrote:
> Hi Simon
>
> The cases (a) and (b) are used on tomahawk, (b) seems like an abstract
> pattern (all classes implementing b on tomahawk starts with
> AbstractXXXX).
>
> The cases (a) and (c) are used on myfaces core.
>
> One example of (b) is this:
>
> /*
> * @JSFComponent
> * name = "t:checkbox"
> * class = "org.apache.myfaces.custom.checkbox.HtmlCheckbox"
> * superClass =
> "org.apache.myfaces.custom.checkbox.AbstractHtmlCheckbox"
> * tagClass = "org.apache.myfaces.custom.checkbox.HtmlCheckboxTag"
> */
> public abstract class AbstractHtmlCheckbox
> extends UIComponentBase implements UserRoleAware
> {
> }
>
> Please look that the superclass is the hand written class. The
> attribute class (or clazz on annotations) refers the class to be
> generated. This plugin checks on the paths defined by the user (max 2
> default src/main/java) if the file exists. If this is true, then not
> generate, if is true generate.
Ok.
I would have thought that this would work the other way around, ie the
user would set superClass to enable the "template" mode, and otherwise a
subclass would be generated.
It seems a little odd to me that to generate a class that subclasses the
annotated class, it has to repeat its own type in the superClass
property.
Actually, when using "template" mode, is the superClass always the class
that is the parent of the annotated class? If so, then why not have a
setting
template="true"
and do away with the superClass attribute completely?
By the way, what does the JSFComponent.parent attribute do?
Regards,
Simon
