Hi Bruno, The plugin goals for config-file and code generation requires a "myfaces-metadata.xml" file as input which contains all the info about component classes, properties, etc.
For the case where tomahawk extends myfaces-api and myfaces-impl, that file is just available directly from the jar's META-INF dir. This is the step that would have to change. I suppose the plugin could try to reconstruct the necessary metadata just from the info available by analysing the .tld and faces-config.xml files for the third-party lib, and possibly using introspection on the classes. I'm not sure if all the critical info would be recoverable [1]. But if not, then the plugin could certainly get *most* of the data, and the missing bits could then be added by hand. It doesn't sound *too* difficult to code...and once the metadata has been "recovered", the other goals will run fine. [1] There is a JCP in progress at the moment regarding metadata for JSF components, because IDEs are having problems implementing some gui-design features. That seems to me to imply that there is some important data that cannot be deduced from just the .tld, faces-config and classfiles. But I haven't read the JCP docs yet. Regards, Simon Bruno Aranda schrieb: > 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] > <mailto:[EMAIL PROTECTED]>* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Leonardo Uribe schrieb: > > > >On Tue, Mar 18, 2008 at 10:54 AM, [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > <mailto:[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]> > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>> > > > wrote: > > > > On Tue, Mar 18, 2008 at 9:54 AM, [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > > <mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > > > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > <mailto:[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 > >
