Leonardo Uribe schrieb:


On Mon, Jul 7, 2008 at 11:43 PM, Jihoon Kim <[EMAIL PROTECTED] <mailto:[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.

But JSFProperty does assume that there is a real field on the component, which is not what Jihoon Kim wants.

I was looking at this a couple of weeks ago, and from memory one of the JSFJsp* annotations really does work fine when you want real properties declared in the tld (and present as methods on the tag class) but just want the data pushed into the component's attributes map rather than stored as a property on the component. So I was going to propose renaming that annotation to JSFAttribute. Unfortunately I cannot remember which annotation it was. I'll have a look on my home pc after work today.

I guess the alternative is to put a flag on the @JSFProperty annotation to indicate that it is an "attributes map only" property. But that does require a real method on the component to attach the annotation to, which is not right for attribute-map-based properties. Maybe we could allow an @JSFProperty annotation to be attached to a public static final string field on the component itself; each component that supports an attribute really should have a constant defined which other classes can then use to fetch that attribute from the attributes map. When the plugin finds a JSPProperty annotation attached to a constant, then it could set the internal "isAttribute" flag on the corresponding PropertyMeta object so that we know to skip that PropertyMeta when generating the saveState/restoreState methods. Thoughts?

Regards,
Simon

Reply via email to