On Mon, Jul 7, 2008 at 11:43 PM, Jihoon Kim <[EMAIL PROTECTED]> wrote:
> Hi, > > I had some questions while refactoring the code using the annotations > of myfaces-builder-plugin and was wondering if I was simply using it > incorrectly or if it is yet to be implemented [since I am currently > pointing to the snapshot repository of the plugin]. > > (1) JSFProperty annotation seems to work intuitively as suggested in > creating the get + set methods of the properties, but I was wondering > about the properties for JSFJspProperties + JSFJspProperty. > > Since I wanted the components that didn't utilize the fields > frequently to be pushed to the Map [so to make the code cleaner], I > was hoping to use these annotations for the fields, but I apparently > do not see them being generated within the Tag of the components and > the tld as I thought they would be generated at. > > The following annotation is within a blank interface of an abstract > class to be created as concrete with JSFComponent annotation : > > @JSFJspProperty > name = "allowMultipleSelection" > returnType = "java.lang.String" > longDesc = "A flag that indicates whether you can allow more than > one item to be selected at the same time." > @JSFJspProperties and @JSFJspProperty is used only as a last resource, when you want to define a property used on the tld but not defined on the component (like "binding" property) or a parent component property should not be on the tld of the child component, and you cannot change the api of the component like in myfaces core (you cannot add public methods to components). If you are working with new components use @JSFProperty instead and avoid any usage at possible of @JSFJspProperty. > > (2) Also, out of curiosity will there be support for multiple > extension of interfaces? Meaning I initially tested with one interface > that extended many other interfaces so to make the number of > interfaces smaller and cleaner for the would be created concrete > component, but wasn't sure if that is in the future plan of > implementation. > Interface support is simple and does not handle inheritance for interfaces. The reason is that in this specific case, interfaces can be seen as a set of related properties (EventProperties, StyleProperties), or a single property definition shared by multiple properties. It is not common to handle subsets of properties. There are other alternatives to handle this like create a hierarchy of components. If you think that this feature has some benefits, or a possible scenario that needs it, you can submit a patch with the arguments about why do that and we can discuss it on the dev list. We are always open to contributions ;-). > Thanks!!! > > Oh yeah, I think the plugin is awesome. > I think the same too! regards Leonardo Uribe > > -- > Sincerely, > > Ji Hoon Kim >
