You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beehive.apache.org by st...@apache.org on 2006/01/14 00:49:05 UTC
svn commit: r368921 [2/2] - in
/beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls:
overview.xml programming.xml
Modified: beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/programming.xml
URL: http://svn.apache.org/viewcvs/beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/programming.xml?rev=368921&r1=368920&r2=368921&view=diff
==============================================================================
--- beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/programming.xml (original)
+++ beehive/trunk/docs/forrest/release/src/documentation/content/xdocs/controls/programming.xml Fri Jan 13 15:48:57 2006
@@ -24,7 +24,7 @@
(with implied semantics) on the Control using metadata-annotated interfaces.
</li>
<li>
- JSR-175 metadata attributes and external configuration data: provides an
+ metadata attributes and external configuration data: provides an
enhanced configuration model for resource access.
</li>
</ul>
@@ -102,13 +102,14 @@
</p>
<ul>
<li>
- <strong>Simplicity.</strong> A key goal of any ease-of-use programming model is to free the developer from
- worrying about plumbing. Managing property values, event listener lists, and other basic JavaBean functions are
- fairly rote from implementation to implementation. The Controls architecture employs a unique variant of the
- Inversion of Control (IoC) design pattern based on JSR-175 metadata. This enables a Control Implementation Class
- to declaratively specify the events or services it requires to provide its semantics. The ControlBean Generated
- Class acts as a lightweight container to provide contextual hookup and implementation details.
- </li>
+ <strong>Simplicity.</strong> A key goal of any ease-of-use programming model is to free the
+ developer from worrying about plumbing. Managing property values, event listener lists, and
+ other basic JavaBean functions are fairly rote from implementation to implementation. The
+ Controls architecture employs a unique variant of the Inversion of Control (IoC) design
+ pattern based on metadata annotations. This enables a Control Implementation Class to
+ declaratively specify the events or services it requires to provide its semantics. The
+ ControlBean Generated Class acts as a lightweight container to provide contextual hookup and
+ implementation details. </li>
<li>
<strong>Consistency.</strong> Instead of trying to provide consistency through convention, the Control compiler
provides both verification and code generation services to ensure that the resulting implementation provides
@@ -357,7 +358,7 @@
</p>
<p>
The second example below shows initialization of the myJmsControl field again. In this case, an initial value of
- the @Destination "name" attribute is also provided using JSR-175 metadata:
+ the @Destination "name" attribute is also provided using metadata annotations:
</p>
<p>
<strong>Declarative Instantiation with Properties (Client Code)</strong>
@@ -368,10 +369,10 @@
@Control
<strong>@Destination(name="InvoiceQueue")</strong>
public JmsMessageControlBean myJmsBean;</source>
- <p>
- This example performs <strong>exactly</strong> the same initialization as the earlier declarative example, but
- does so using JSR-175 attribute syntax instead of passing parameters to a factory-based constructor.
- </p>
+ <p> This example performs
+ <strong>exactly</strong> the same initialization as the earlier declarative example, but
+ does so using annotation attribute syntax instead of passing parameters to a factory-based
+ constructor. </p>
<p>
The Controls architecture includes a mechanism for defining the expected set of annotations that might appear on
a Control field. This mechanism is described in greater detail in the section on Properties.
@@ -933,9 +934,8 @@
capabilities:
</p>
<ul>
- <li>
- A declarative annotation model where properties can be preconfigured on a ControlBean using JSR-175 annotations
- </li>
+ <li> A declarative annotation model where properties can be preconfigured on a ControlBean using
+ metadata annotations </li>
<li>
An administrative model where the value of ControlBean properties can be externally defined or overridden.
</li>
@@ -956,12 +956,11 @@
model for JavaBean accessors, etc) and will have property names based upon a common naming
convention.
</p>
- <p>
- A PropertySet is declared as a JSR-175 attribute interface within the Control Public Interface,
- which is also decorated with the org.apache.beehive.controls.api.properties.PropertySet
- meta-attribute. Each of the members within a PropertySet will refer to a distinct property
- within the set, and the return value of the member defines the property type.
- </p>
+ <p> A PropertySet is declared as a metadata attribute interface within the Control Public
+ Interface, which is also decorated with the
+ org.apache.beehive.controls.api.properties.PropertySet meta-attribute. Each of the
+ members within a PropertySet will refer to a distinct property within the set, and the return
+ value of the member defines the property type. </p>
<p>
Here is a sample declaration of the Destination PropertySet for the JmsMessageControl, which can
be used to configure the target JMS destination for the Control:
@@ -1324,11 +1323,10 @@
The body of the message will be a single instance of the Order class, and it will have a single StringProperty
with the expected delivery date (enabling message selector-based queries for orders that are past due).
</p>
- <p>
- The message format (in this case an ObjectMessage) and the mapping of operation parameters to message content
- and/or properties are all defined using JSR-175 metadata on the method or its parameters. This format makes it
- very easy for tools to assist in the creation and presentation of extension interfaces.
- </p>
+ <p> The message format (in this case an ObjectMessage) and the mapping of operation parameters to
+ message content and/or properties are all defined using metadata annotations on the method or
+ its parameters. This format makes it very easy for tools to assist in the creation and
+ presentation of extension interfaces. </p>
<p>
How does the extension author (or tool) know about the set of annotations that can be used on the extension
interface? This is the topic of the next section.
@@ -1340,11 +1338,10 @@
A Control author is responsible for defining the extensibility semantics for a particular type, since ultimately
they are responsible for providing the implementation that fulfills the semantics.
</p>
- <p>
- The extension semantics for a Control are part of the public contract for the Control, and thus are defined on
- the Control Public Interface as well. As with Control properties, these are defined in the form of JSR-175
- annotation interfaces, as show in the following sample code from the JmsMessageControl Public Interface:
- </p>
+ <p> The extension semantics for a Control are part of the public contract for the Control, and thus
+ are defined on the Control Public Interface as well. As with Control properties, these are
+ defined in the form of metadata annotation interfaces, as show in the following sample code
+ from the JmsMessageControl Public Interface: </p>
<p>
<strong>Declaring Extension Semantics (Control Public Interface)</strong>
</p>