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, etc. 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 and modular.