There is a long list of object models for which [clazz] may be
relevant. For each of them we need to decide whether to
[+1] support directly
[-1] not to support at all
[D] allow support via delegation
Let's start building that list and decide for each model what level of
support we want to have in [clazz]
- JDK JavaBeans per JavaBean spec
Dmitri: [+1] I think enough projects have a dependency on the JDK
definition of JavaBeans for [clazz] to strictly support it
- Extended JavaBeans.
This includes the new mapping schemes for collection/indexed
properties, simplified SmallTalk-style method names etc. In addition
to indexed properties may support mapped ones.
Dmitri: [+1] This is a reasonable extension of JavaBeans, feels
almost like an upgrade
- DynaBeans (see BeanUtils)
Dynamic imitation of JavaBeans: DynaClass is just like Class, except
it is dynamic and mutable, DynaBean is like a Map, only strongly typed
with the help of DynaClass. WrapDynaBean bridges between DynaClass and
regular Class for the unification of object access APIs.
Dmitri: [D] We cannot ignore DynaBeans since they are already widely
used, but as they are a part of BeanUtils, we probably want to delegate
their support entirely to BeanUtils.
- Maps and DynamicProperty objects
A Map (aka Dictionary, Properties, DynamicProperty object) are
completely untyped. Property list is open ended. DynamicProperty
object is a Map or an object with characteristics similar to a map e.g.
HttpServletRequest. One way to cover all DynamicProperty object at
once is through delegation. For example, in [jxpath] you provide a
static DynamicPropertyHandler object for each such model.
Dmitri: [D] Since the list of object models similar to maps is so
big, the only reasonable way to handle them appears to be delegation.
- EJB Entity Beans, Statefull Sessions
Several major differences from regular beans:
a) the implementation class is unknown (generated by container),
therefore a BeanInfo-style customization mechanism won't work.
b) instantiation is factory-based (EJB home).
c) remote entity beans typically use ValueObjects instead or in
addition to regular access methods.
Dmitri: [D] We don't want to introduce a dependency on J2EE in
[clazz], therefore EJB support wants to be in a separate project.
However EJBs are common enough, so their support should be possible.
- EJB Stateless Session
Not a bean - does not have properties or relationships, only
methods.
Dmitri: [-1] I say, ignore services for now.
- WebService
Not a bean - only methods.
Dmitri: [-1] Why mix oil and water? Let's focus on beans for now.
- DOM, JDOM etc
Several differences from beans:
a) two ways to capture properties: elements and attributes
b) no collections
c) element with the same tag can appear more than once, thus we
can say that in DOM properties are not unique.
Dmitri: [?] I have not formed my opinion on this one yet. Some will
use the same oil/water analogy for DOM/JavaBeans. I think it might be
challenging to generalize the programming model over both of them.
Examples: JavaScript, JXPath. I will be honest with you - I am not
entirely satisfied by the way JXPath does that.
- JDO, OJB
We will need to determine if there is anything special about the
beans handled by these two.
What other models do we care about?
- Dmitri
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
