myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "simon.kitching@chello.at" <simon.kitch...@chello.at>
Subject Re: [Tomahawk] Commit of component generation and 1.2 modules to trunk
Date Wed, 19 Mar 2008 08:17:20 GMT
Leonardo Uribe schrieb:
> >On Tue, Mar 18, 2008 at 10:54 AM, simon.kitching@chello.at
> <mailto:simon.kitching@chello.at> <simon.kitching@chello.at
> <mailto:simon.kitching@chello.at>> wrote:
> >[1] I'm not sure what the later property examples on that page are meant
> >to be; as Leonardo has written them they are attached to no function
> >which is not what I had in mind...
>
> Thanks Simon for make more clear this on the wiki page. I have also
> added comments about how
> should work isSetFieldMethod and isGetLocalMethod attributes for
> @mfp.property.

And thanks for your additions.

Is the "setLocalMethod" stuff specifically something that trinidad
needs? I have not seen this anywhere in core or tomahawk that I
remember. If so, then perhaps the wiki could say (trinidad only) or
similar next to those props.
>
> On Tue, Mar 18, 2008 at 12:44 PM, Andrew Robinson
> <andrew.rw.robinson@gmail.com <mailto:andrew.rw.robinson@gmail.com>>
> wrote:
>
>     On Tue, Mar 18, 2008 at 9:54 AM, simon.kitching@chello.at
>     <mailto:simon.kitching@chello.at>
>     <simon.kitching@chello.at <mailto:simon.kitching@chello.at>> wrote:
>     > Hi Andrew,
>     >
>     >  Andrew Robinson schrieb:
>     >
>     > > One major drawback to the javadoc annotation approach has been
>     left
>     >  > out and that is attribute reuse. The maven-faces-plugin
>     allows you to
>     >  > import XML fragments using XPath. So in Trinidad, onclick,
>     >  > onmouseover, onmouseout, etc. you can import one XML file and
>     not have
>     >  > to re-define all these. But with the javadoc approach, you
>     have to
>     >  > either one, try to hack the code to extend other classes, two
>     have
>     >  > some weird interface usage to import these. Either way, the
>     object
>     >  > hierarchy has to be hacked to get it to work.
>     >  >
>     >
>     >  Hmm..interesting. So trinidad has cases where a class X is not
>     related
>     >  to A by inheritance, but does want to provide the same
>     properties as A?
>     >
>     >  Java currently defines "implements" and "extends"; sounds like
>     Trinidad
>     >  has invented a new OO concept, "emulates" :-).
>
>     No, it only imports certain attributes, not all of them. Take some
>     time to look at the trinidad-build project and how it works. It is
>     better to see than explain.
>
>
> In tomahawk, there are interfaces like
> org.apache.myfaces.component.UserRoleAware that define getter and
> setter methods for a particular group of related properties. Maybe we
> can do something like this:
>
> /**
>  * @mfp.interface //or propertiesinterface or setofproperties or
> anything related
> **/
> public interface UserRoleAware
> {
>     static final String ENABLED_ON_USER_ROLE_ATTR = "enabledOnUserRole";
>     static final String VISIBLE_ON_USER_ROLE_ATTR = "visibleOnUserRole";
>
>     /**
>      * @mfp.property
>    **/
>     String getEnabledOnUserRole();
>
>     void setEnabledOnUserRole(String userRole);
>
>     /**
>      * @mfp.property
>    **/
>     String getVisibleOnUserRole();
>
>     void setVisibleOnUserRole(String userRole);
> }
>
> Then  the abstract component class can implements this interface and
> finally the generated class must implement the methods. In this way we
> make clearer the API, and eliminate in a clean way the advantage of
> using xml files.

I see. Yes, where is a group of properties to be shared between two
classes, the OO way would be to declare a common interface.

I guess another example is the set of "html passthrough attributes" that
is attached to many components.

The myfaces-builder-plugin code already walks interfaces looking for
property definitions. Currently the normal "@mfp.component" annotation
is looked for even on interfaces (the plugin already knows that this is
an interface) but a different annotation could also be introduced.

An alternative might be to have
    @mfp.property group="userRole"
and
   @mfp.component usePropertyGroups="userRole, htmlAttributes"
but I prefer the interface approach. Does trinidad pull subsets of
properties from the myfaces-api classes? If so, then the
usePropertyGroups would be necessary as we cannot factor out interfaces
for the javax.faces classes.


The point you made about overriding documentation appears to be the
ugliest part of the doc-annotation based approach. In the wiki page I
have a "delegating method" just to override the comment, which is really
not nice. Any suggestions for a better answer to this would be welcome...

Regards,
Simon


Mime
View raw message