Hi, is this possible with the myfaces-builder-plugin to extend components that are part of another jar library (e.g. extending a tomahawk component from a third-party lib)?.
Cheers! Bruno On 19/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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 > >
