Another question about this: How is the control developer supposed to set up the external configuration mechanisms? Does he have to implement it up from scratch?
On 1/13/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote: > > Xibin-- > > Yes, you're right about the @PropertySet(externalConfig=true) > annotation -- it denotes external overridability as well. > > As far as the @AllowExternalOverride annotation, I believe that (in > part) it replaced @AccessModes, but I don't think that it should be > deprecated. The @PropertySet annotation does two things: > > - supports declaring a *set* of annotation attributes as externally > configurable > - changes the shape of the generated ControlBean to have JavaBean > getter / setter methods for each annotation attribute > > In particular, @PropertySet works for class-level annotations. > > @AllowExternalOverride allows an annotation author to configure a > *single* annotation as externally overridable without changing the > shape of the ControlBean. This is really useful for method and > parameter annotations that might need to be configured externally. > > That's my take -- @PropertySet supports one set of use cases, and > @AllowExternalOverride supports a different one. So, I don't think > that we should deprecate either. :) > > My $0.02... > > Eddie > > > > On 1/13/06, Xibin Zeng <[EMAIL PROTECTED]> wrote: > > Eddie and Steve - > > > > It looks like either @PropertySet(externalConfig=true) or > > @AllowExternalOverride can be used to indicate the external > configurability > > of an annotation, should @AllowExternalOverride be deprecated? The > reason to > > favor @PropertySet(externalConfig=true) is that it is in the same place > > where programmatic access to property sets are generated. (There is a > > precedence rule on how control resolves the value, programmatic, > external > > config are among the mechanisms to set properties.) > > > > Thanks > > Xibin > > > > On 1/12/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote: > > > > > > Steve-- > > > > > > Good catch -- while automatic generation of the shape for an > > > external override XML file could be a great feature to have, we don't > > > have that today (that I know of). Additionally, this annotation: > > > > > > @AccessModes > > > > > > doesn't exist in Controls any longer. The external overridability of > > > an annotation property value is specified via the > > > @AllowExternalOverride meta-metadata -- if you will. :) > > > > > > We should fix that in this doc. Also, we should also remove > > > references to "JSR-175" metadata and just call it Java 5 metadata / > > > annotations (or just metadata / annotations). The JSR number isn't > > > that useful. :) > > > > > > Eddie > > > > > > > > > > > > On 1/12/06, Steve Hanson <[EMAIL PROTECTED]> wrote: > > > > Hi all: > > > > > > > > This section of the doc describes the generation of an XML schema on > the > > > > compilation of a control: > > > > > > > > > > > > http://beehive.apache.org/docs/1.0/controls/overview.html#A+Flexible+Property+Model > > > > > > > > It claims that you can configure your control attributes > through XML > > > files > > > > that accord with the shema. > > > > > > > > Is this really true? I have noticed that there is an > "externalConfig" > > > > property on the @PropertySet ( > > > > > > > > http://beehive.apache.org/docs/1.0/apidocs/classref_controls/org/apache/beehive/controls/api/properties/PropertySet.html#externalConfig() > > > > ). > > > > > > > > But then the trail runs cold. If there is more to this trail, could > > > someone > > > > fill me in. Otherwise I will cut this section from the doc. > > > > > > > > Thanks, > > > > Steve Hanson > > > > > > > > > > > > > > > >
