On Sun, Jun 1, 2008 at 4:33 AM, simon <[EMAIL PROTECTED]> wrote:
>
> 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.
>
One idea is allow write the superClass without package definition like this
superClass ="AbstractHtmlCheckbox"
>
> 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?
>
Actually, the plugin has two settings on ComponentMeta
generatedComponentClass
generatedTagClass
This settings are written automatically by QdoxModelBuider (this settings
are necessary for avoid copy of this classes by unpack goal).
>
> By the way, what does the JSFComponent.parent attribute do?
>
parent works in this situations:
/*
* @JSFComponent
* name = "t:collapsiblePanel"
* class =
"org.apache.myfaces.custom.collapsiblepanel.HtmlCollapsiblePanel"
* parent = "javax.faces.component.UIOutput"
* superClass =
"org.apache.myfaces.custom.collapsiblepanel.AbstractHtmlCollapsiblePanel"
* tagClass =
"org.apache.myfaces.custom.collapsiblepanel.HtmlCollapsiblePanelTag"
*/
public abstract class AbstractHtmlCollapsiblePanel extends UIInput
implements StyleAware, UniversalProperties, EventAware,
UserRoleAware
This component extends from UIInput, but does not have any attributes
defined in its tld of this component. In other words, parent is a hack for
avoid define @JSFProperty tagExcluded="true" or @JSFJspProperty
tagExcluded="true". There is several component on tomahawk that uses it.
"parent" is also used on schedule component in this way:
/*
* @JSFComponent
* parent = "org.apache.myfaces.custom.schedule.UIScheduleBase"
*/
public class UISchedule extends UIScheduleBase implements
Serializable, ActionSource
UIScheduleBase is generated, so QdoxModelBuilder does not resolve it
(because this class doesn't exists! before build myfaces-metadata).
In conclusion, "superClass" and "parent" are different concepts. "parent" is
a component defined on the model, so the component defined by @JSFComponent
annotation inherits properties. "superClass" is used in the template.
I think we can avoid "superClass", but I'm not have clear how we can do this
in a cleaner way. On myfaces core 1.1 this is used:
/*
* @JSFComponent
* name = "h:message"
* class = "javax.faces.component.html.HtmlMessage"
* tagClass = "org.apache.myfaces.taglib.html.HtmlMessageTag"
* desc = "h:message"
*/
abstract class _HtmlMessage extends UIMessage implements _StyleProperties,
_MessageProperties
The superClass by default is the class which extends, in this case UIMessage
(and the "parent" too!). In this case there is also a generated class, so
use an attribute like "generatedComponentClass = true" not resolve the
problem. Maybe if we use a setting like this:
generationPattern = "abstract" // (default)
and
generationPattern = "template"
and remove superClass could work (we need a revision of all generation we
have to check if this is true).
Suggestions are welcome
regards
Leonardo Uribe
>
> Regards,
> Simon
>
>
