Mailing-List: contact dev-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Developers" <dev@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of kentaminator@gmail.com
 designates 66.249.92.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        b=rtPgQdD1sazL5GvGzNalNgS/c/md6Pi726KIw7OF9kEzu71/aSgVBTudlBWotqPr40oprZjj/oP4g2marAihDmRYuw04BuDI8NRL6mnP50hDAtzJId1P7m7m+jLsdSytNqKgbi8hkcEWlgIDs2lWfOG7IZ/R9vBiYdhBRWG01J4=
Message-ID: <e52f74f80607121850r192e7c23ve7f1a17c1f1c55d3@mail.gmail.com>
Date: Wed, 12 Jul 2006 18:50:42 -0700
From: "Kenneth Tam" <kentaminator@gmail.com>
To: "Beehive Developers" <dev@beehive.apache.org>
Subject: "Hornet" controls sandbox
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I just checked in a sandbox project named "Hornet", that has code
exploring some ideas I'm having about controls.  It's a maven2 project
and should be really easy to build; just sync sandbox/hornet, install
maven 2.0.4 and run "mvn" inside sandbox/hornet/controls.

Beehive "Hornet"

Guiding Principals
==================

Features should be as modular and independent as possible; user buy-in
can be incremental, you only pay for what you need.

Proposal: Eliminate generated ControlBean construct.  All access is
via control interface, implying that all functionality that used to
exist only on the controlbean either has to get surfaced to the
interface, removed, or exposed via some other mechanism.

Benefits: Significantly reduces the complexity of the controls model
by removing an entire conceptual artifact.  Having a generated control
bean, understanding why it exists and when to use it vs the control
interface has always been confusing for users.  It also complicated
integration with other technologies, since the controlbean essentially
defined its own container, complete with injection.  Testability is
improved; you can mock a control by mocking the control interface
without losing surface area, and instantiation/configuration is
simplified.

---

Feature: Control instantiation/declaration:
===========================================

Proposal: Simple control instantiation consists merely of calling the
implementation constructor.  Extensible control instantiation consists
of constructing a dynamic proxy that implements the control interface
and delegates to the control implementation.

Benefits: Simplifies integration into other frameworks; minimal
overhead, proxy only when necessary.

---

Feature: Class and instance level properties:
=============================================

(Currently, such properties were defined via nested annotation
definition on the interface, and results in generated accessors on the
controlbean (a point of some user confusion))

Proposal: Follow standard JavaBean model for class & instance level
properties -- define them via the presence of accessors on the control
interface (property name is inferred from the accessor name per
standard JavaBean property conventions).

Proposal: For class and instance level properties, @PropertySet
annotations are optional and sub-ordinate to accessors for property
definition.  @PropertySet naming and prefix must correspond to
accessor names rather than the other way around.

Benefits: Developers already understand what JavaBean properties are;
rather than force them to think about them in terms of annotations
(@PropertySets) in order to define them, this makes it clearer that
annotations are just another (optional) way to set properties -- they
don't attempt to _define_ properties.  Simplifies integration with
other injection frameworks, which get to treat the interface as a 1st
class entity (functionality is not hidden).  Annotation overriding is
more obvious (just use the setters).  Removes the artifical limitation
annotations impose on property types.

Drawbacks: Control authors have to think about potentially keeping
accessor methods & PropertySet annotations synchronized.  Tooling is a
has a straightforward solution to this, but even in its absence,
command-line compilation tools can help greatly.

Proposal: Expand tooling support for enforcing strong property types
and constraints on all properties, not just those that are set using
annotations (ie, allow @AnnotationConstraints and
@AnnotationMemberTypes functionality to generic JavaBean properties by
annotating accessors).  Note that Spring supports container
enforcement like this via RequiredAnnotationBeanPostProcessor; we
could expand this to include "all if any" and other rules in
@AnnotationConstraints, and provide that support in container-neutral
form.

---

Feature: Method and parameter level properties:
===============================================
It's unclear how much real value there is in providing a richer
backing store for method and param level property data; there are
namespacing issues, and I haven't seen many interesting usecases for
being able to set a method-level property via e.g. an accessor -- I'd
love to hear some and dig into what might be a good model for
supporting that.

Per the last proposal bullet re: tooling support for enforcing
property types/constraints, that's definitely a point of continued
value-add for method and parameter level properties.

---

Feature: Support for runtime access to method parameter names:
==============================================================

Proposal: Explicitly expose parameter name via an @PName annotation on
parameters.

While the current approach of generating BeanInfo requires less
authoring, the cost of additional artifact generation is high.  Other
frameworks have addressed the parameter naming problem (c.f. Spring's
*SqlParameterSource classes), and the language itself is in-flight to
addressing it (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082475).
 Requiring an explicit annotation is redundant, but easily tooled, and
makes the feature very lightweight, modular and pluggable.

There's a ton of other stuff I haven't elaborated on.. getting out of
the interceptor business, exposing contextual services as just another
kind of injected dependency, questioning the value of the eventing
model and how to make it more a la carte, etc.

The sandbox code is really primitive, but my main goal is to
illustrate some of the points I mention above..  A key to guiding my
approach here was looking at the system controls (which are probably
among the more complex and interesting use cases) and trying to see
how the core functionality they used could be supported in as
lightweight a fashion as possible.  I started with the JDBC control;
the sandbox has a forked copy to which I made the minimum # of changes
to get to compile against the the new API/runtime.. no runtime tests
yet, but it should be pretty close.

k