Date: 2004-08-16T23:12:47
Editor: KenTam <[EMAIL PROTECTED]>
Wiki: Apache Beehive Wiki
Page: Controls/AssemblyAndBinding
URL: http://wiki.apache.org/beehive/Controls/AssemblyAndBinding
no comment
Change Log:
------------------------------------------------------------------------------
@@ -14,11 +14,11 @@
Control clients MUST declaratively identify all control types they use. This
is accomplished via 2 annotations, which are handled by the control client
annotation processor:
[EMAIL PROTECTED] -- marker annotation valid on fields; the annotated field's
type is a control type (directly, as the PI, or indirectly as the generated CB
that maps to a PI).
[EMAIL PROTECTED] -- marker annotation valid on fields; the annotated field's
type is a control type (directly, as a control interface/extension, or
indirectly as the generated ControlBean that implements a control
interface/extension).
[EMAIL PROTECTED] -- single value annotation valid on classes or methods; the
annotation's value specifies the a control type that the control client uses.
[EMAIL PROTECTED] are required whenever a client uses a control type in a
purely programmatic way (ie, there is no [EMAIL PROTECTED] annotated field of
that control type in the client).
-{{{TBD: elaborate on how this might work for non-Java clients}}}
+{{{TBD: elaborate on how this might work for clients that are Java-centric,
but aren't "plain Java code", e.g. JSPs, BPELJ, etc.}}}
Both annotations have runtime retention policy; thus in principle, the
assembly process may accept a set of control clients made of up of a mixture of
source and binary classes, and use reflection to determine the set of control
types those clients use.
@@ -41,14 +41,14 @@
== Implementation Binding ==
-The default implementation binding for a control type is defined by the
defaultBinding attribute on the [EMAIL PROTECTED] annotation. The expectation
is that overriding the default binding is an unusual occurrence. The
conventional approach to overriding an annotation value would be via a
deployment plan, however, since the binding affects assembly, it needs to take
place prior to application deployment (we consider assembly to be properly part
of the build).
+The default implementation binding for a control type is defined by the
defaultBinding attribute on the [EMAIL PROTECTED] annotation. The expectation
is that overriding the default binding is an unusual occurrence. The
conventional approach to overriding an annotation value would be via
[http://www.jcp.org/en/jsr/detail?id=88 deployment descriptors], however, since
the binding affects assembly, it needs to take place prior to application
deployment (we consider assembly to be properly part of the build).
{{{
REVIEW: this almost suggests that assembly is part of deployment, but on
deeper thought that seems clearly wrong. I am not completely satisfied with
this yet. I think we need to really define crisply whether binding is a
developer or admin feature.
}}}
External configuration of bindings is supported via a "controls binding file",
an optional, user-authored, application scoped properties file that contains:
- * bindings between C''''''ontrolBean/interface types and control
implementation types. Each binding applies to all usages of the CB/interface
type within that app.
+ * bindings between C''''''ontrolBean/interface types and control
implementation types. Each binding applies to all usages of the
ControlBean/interface type within that app.
Example controls binding file (e.g. {{{MyApp.controls.properties}}})
{{{
