You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Jihoon Kim <ji...@gmail.com> on 2008/07/08 06:43:46 UTC
Clarifications requested regarding the usage of annotations within the myfaces-builder-plugin
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."
(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.
Thanks!!!
Oh yeah, I think the plugin is awesome.
--
Sincerely,
Ji Hoon Kim
Re: Clarifications requested regarding the usage of annotations within the myfaces-builder-plugin
Posted by Leonardo Uribe <lu...@gmail.com>.
On Tue, Jul 8, 2008 at 3:46 PM, simon <si...@chello.at> wrote:
>
> On Tue, 2008-07-08 at 10:35 +0200, simon.kitching@chello.at wrote:
> > Leonardo Uribe schrieb:
> > >
> > >
> > > On Mon, Jul 7, 2008 at 11:43 PM, Jihoon Kim <jihoonkim1004@gmail.com
> > > <ma...@gmail.com>> 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?
>
This part ilustrate the parts where @JSFJsfProperty is useful. Look this
code on myfaces core 1.2:
@JSFComponent(type = "javax.faces.ComponentBase",
family = "javax.faces.ComponentBase",
desc = "base component when all components must inherit",
tagClass = "javax.faces.webapp.UIComponentELTag")
@JSFJspProperty(name = "binding" ,
returnType = "java.lang.String",
longDesc = "Identifies a backing bean property (of type
UIComponent or appropriate subclass) to bind to this component instance.
This value must be an EL expression.",
desc="backing bean property to bind to this component
instance")
public abstract class UIComponentBase
extends UIComponent
{
getBinding() or setBinding does not exists on UIComponentBase (does not have
sense), but it is defined on its tld, so we need to use it. But look what
happen on UIViewRoot.
@JSFComponent
@JSFJspProperty(name = "binding",returnType = "java.lang.String",tagExcluded
= true)
public class UIViewRoot extends UIComponentBase
{
UIViewRoot does not have binding property, so we need a way to exclude it.
In tomahawk there are other cases of the last example like this:
* @JSFComponent
* name = "t:jsValueChangeListener"
* class = "org.apache.myfaces.custom.jslistener.JsValueChangeListener"
* tagClass =
"org.apache.myfaces.custom.jslistener.JsValueChangeListenerTag"
*
* @JSFJspProperty name = "rendered" returnType = "boolean" tagExcluded =
"true"
* @JSFJspProperty name = "binding" returnType = "java.lang.String"
tagExcluded = "true"
* @JSFJspProperty name = "id" returnType = "java.lang.String" tagExcluded =
"true"
*/
public abstract class AbstractJsValueChangeListener extends UIComponentBase
{
>
> 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.
>
Strange case. It is valid to have a property without getter and setter on
its component class and defined on its tag class and its tld? isn't this
cause a lot of problems with facelets, because you have to write your own
handler class to manage this?. "binding" property is the only valid case
that I have found.
>
>
> Regards,
> Simon
>
>
Re: Clarifications requested regarding the usage of annotations within the myfaces-builder-plugin
Posted by Jihoon Kim <ji...@gmail.com>.
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 <si...@chello.at> wrote:
>
> On Tue, 2008-07-08 at 10:35 +0200, simon.kitching@chello.at wrote:
>> Leonardo Uribe schrieb:
>> >
>> >
>> > On Mon, Jul 7, 2008 at 11:43 PM, Jihoon Kim <jihoonkim1004@gmail.com
>> > <ma...@gmail.com>> 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
Re: Clarifications requested regarding the usage of annotations
within the myfaces-builder-plugin
Posted by simon <si...@chello.at>.
On Tue, 2008-07-08 at 10:35 +0200, simon.kitching@chello.at wrote:
> Leonardo Uribe schrieb:
> >
> >
> > On Mon, Jul 7, 2008 at 11:43 PM, Jihoon Kim <jihoonkim1004@gmail.com
> > <ma...@gmail.com>> 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
Re: Clarifications requested regarding the usage of annotations within
the myfaces-builder-plugin
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Leonardo Uribe schrieb:
>
>
> On Mon, Jul 7, 2008 at 11:43 PM, Jihoon Kim <jihoonkim1004@gmail.com
> <ma...@gmail.com>> 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
Re: Clarifications requested regarding the usage of annotations within the myfaces-builder-plugin
Posted by Leonardo Uribe <lu...@gmail.com>.
On Mon, Jul 7, 2008 at 11:43 PM, Jihoon Kim <ji...@gmail.com> 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
>