beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kenneth Tam" <>
Subject Controls "the next generation"
Date Wed, 21 Jun 2006 00:32:37 GMT
I've had a few conversations recently about what kinds of
changes/improvements might make sense for Beehive controls to make
them more accessible and usable in light of all the changes that have
gone on in the Java development world since controls were originally
designed.  Here are some rough thoughts/ideas I've had; I'll probably
start exploring some of these ideas in the coming weeks via
prototyping in a sandbox and post more detailed explanations of what
I'm thinking.

Rearchitecture to incorporate support for various contemporary
container and ease-of-development technologies, and strea
mline/modularize feature-set based on developer feedback.

Support strong separation of service provider/consumer concerns
 - continue to expect control implementation authors (service
providers) to be more highly skilled Java developers than
 - focus more on adding value to consumers, less on making it easier
for the provider (plenty of other technologies in t
hat space).
   - controls _usage_ should continue to be highly toolable

Key use case is consumers authoring interface extensions for extensible controls
 - rich support for provider-defined annotation grammars & associated semantics
 - think of controls as making Java dynamic proxies easy &
annotation/metadata driven.
  - focus on resource access / smart proxy problem

De-emphasize nested controls case
 - controls no longer positioned as generic logic containers
 - just write pojos, use other containers and their features
 - limit or refactor eventset support (how important has this been in
actual usage)?

Make it easier to use controls from anywhere by reducing/refactoring
container requirements
 - remove or refactor dependency on JavaBeans Runtime Containment and
Services Protocol specification (unclear that valu
e of that framework justifies cost/complexity)
 - consider interop and co-existence with other annotation sets as an
important use case
  - JAX-WS
  - EJB 3
  - JSR-250
 - consider replacing compile-time code-gen with runtime bytecode gen
(asm or cglib style)
 - delegate dependency injection/IoC responsibilities; replace
@Control and @Context
  - expect developers to use injection container of their choice
   - Spring
   - EJB3/JSR-250 (@Resource)
  - refactor declarative property configuration (usage of @Property
annotations on fields marked w/ @Control) to make it
 optional (just another source of injection)
  - pluggable lifecycle support (can we replace ResourceContext?)
   - JSR-250 (@PostConstruct, @PreDestroy)


Would love to hear some comments/feedback, especially about other
ideas of how controls might be more useful in conjunction with all the
other Java technologies that have proliferated in the past few years.

View raw message