Thanks to both for the inputs.
Yeah, I too thought that JSFJspProperty's purpose was simply to push
entries into the Map, which I thought would be great since I didn't
want so many getters + setters within the concrete component to
possibly confuse the developer.
I did actually go through the current source code of how
JSFJspProperty was used and it seems that it's main purpose was to
exclude certain fields from being generated within the Tag + tld
files. Meaning I think the proper syntax is :
@JSFJspProperty
name = "name_to_exclude" [i.e. binding]
...
tagExcluded = true
So the question remains of whether using this annotation to push
entries into the Map or simply having an another attribute of
annotation @JSFProperty [like what Simon mentioned in prior post]
seems of a better choice in relation to current architecture of the
plugin.
When I get some free time after taking care of certain issues during
my current free time, I will try to refresh my knowledge of the maven
plugin and etcetera, so to possibly help out as well [since this does
sound quite interesting].
Thanks and till later!
On Tue, Jul 8, 2008 at 1:46 PM, simon <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-07-08 at 10:35 +0200, [EMAIL PROTECTED] wrote:
>> 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?
>>
>
> Hmm. The annotation I was thinking of was JSFJspProperty. I already
> committed the comment that it can be used for declaring component
> attributes that live only in the attributes map.
>
> But I must have misunderstood Leonardo's intention. Looking at the
> QdoxModelBuilder, there is a comment that this annotation exists only
> "to solve a problem with binding on JSF1.1" (line 1072). I don't
> currently understand what that problem might be. Leonardo?
>
> It would be interesting to also look at Tomahawk though. Don't we
> already have quite a lot of components that have properties on the tag
> that map just into the attributes map, and not to the component? I can't
> remember for the moment how that is set up, but will try to look
> tomorrow.
>
>
> Regards,
> Simon
>
>
--
Sincerely,
Ji Hoon Kim
