myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe" <lu4...@gmail.com>
Subject Re: myfaces-builder-plugin notes
Date Sat, 21 Jun 2008 21:03:15 GMT
Yes it is, is inheritance of properties between tag classes.
For example, if CompB has some property, it must be defined on tagC, but
if CompA has some property, it was already defined (this is the problem,
by default properties that comes from CompA has inheritTag=true for
CompB and CompC).

On 6/21/08, simon <simon.kitching@chello.at> wrote:
>
> On Sat, 2008-06-21 at 15:06 -0500, Leonardo Uribe wrote:
>>
>>
>> On Sat, Jun 21, 2008 at 2:37 PM, simon <simon.kitching@chello.at>
>> wrote:
>>
>>         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?
>>
>>
>>  Right now, the actual approach seems to be the most effective (this
>> problem was a
>> really BIG headache when I did component generation with
>> myfaces-faces-plugin, it
>> takes me many weeks to understand it). I'm open mind to all
>> suggestions, but this
>> part is very, very critical for correct working of tomahawk.
>>
>>  The problem with this approach is how inheritTag param of
>> PropertyMeta works. If you
>> create an abstract class that extends from HtmlCommandButton for
>> example with another
>> tag class and superclass (annotated), you have to set manually all
>> properties with inheritTag = false,
>> to be generated on the tag class (very awful).
>>  =
>
> Hmm. That inheritTag stuff on PropertyMeta is also rather confusing.
>
> >From JSFProperty.java:
> /**
> * Indicate if this property is inherited from a parent tag class or not.
> */
> boolean inheritTag() default false;
>
> What does this mean? Components don't inherit properties from tags...
>
>
> Is this something to do with handling situations like this (<= indicates
> inheritance):
>   CompA <= CompB <= CompC
>    tagA     <=       tagC
> where component B is abstract, and so has no tag class? So it is
> necessary to figure out what setters/getters tagC needs to define?
>
> Or is it something else?
>
> Regards,
> Simon
>>
>
>

Mime
View raw message