Leonardo Uribe schrieb: > >On Tue, Mar 18, 2008 at 10:54 AM, [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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
