>On Tue, Mar 18, 2008 at 10:54 AM, [EMAIL PROTECTED] <
[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.
On Tue, Mar 18, 2008 at 12:44 PM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:
> On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED]
> <[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.
regards
Leonardo Uribe
