Hi Mike
You are *so* right ;-)
> I have been looking at the bean handling mechanism and I can't see how the
> current implementation can work in a generic manner, so I am probably
> missing something, but anyway ..
>
> I can see that the classes appear to be work in progress, but the
mechanism
> allows for the properties of a bean to be mapped as attributes only, which
> gives me some problems
Its more a proof of concept to show how a dual XML <-> JavaBean tree could
be built. Its quite a primitive implementation though.
The simple demo in /src/samples/bean/BeanDemo.java shows how XPath across
XML documents with embedded beans could work.
The idea behind dom4j is that its an easy to use, polymorphic API for
working with XML on the Java platform with Java 2 collections support,
integrated XPath and plugin model implementations. Anyone is welcome to
implement any XML <-> JavaBean bridge however they wish. Though I'd
obviously like a nice one to be part of the standard dom4j distribution ;-)
> 1. If the property is not a string property then a getValue /setValue pair
> will not work as there is no code to map do the reverse of the toString()
> 2. There is no way to do map a structure as an object tree
Agreed.
> Is it proposed that the current implementation would evolve to handle
> element structures, or is there a proposal to generate an additional
package
> for this case.
I'd like it to yes. I think this would be a cool idea - allowing (say) parts
of XML documents or adjuncts or whatever to be turned into beans but the
whole document appears as valid XML in an XPath / XSLT / SAX sense.
I can imagine clever DocumentFactory implementations being written that are
'schema aware' that could (say) make XML Schema Datatypes aware Element and
Attribute implementations or map certain types to JavaBeans and so on. All
based on namespaces probably or XPath expressions...
> I would hope that there could be a general purpose mechanism to allow for
> the duality of an XML based structure and a object structure, and a set of
> rules to allow for the mapping of them, without requiring anything on the
> target bean.
Me too!
> For example
> 1. primitives ( and maybe some other simple cases such as Number) mapped
as
> attributes ( thus allowing for getValue/setValue to work)
> 2. other property types mapped as elements
> 3. ability to specify ( ?via an XML doc) the mapping for attributes and
> elements
> 4. if the object itself is an Element, then behaviour should be delegated
to
> the Element
> 5. Some rules would be required to cope with mapping for the constructors,
> but calling the default constructor should be OK for most circumstances
> 6. specific mechanisms would have to be in place to cope with cyclic
object
> structures, but the marshalling/unmarshalling mechanism could use ID/IDREF
>
> This would allow for serialisation of (bean) object structures to / from
XML
> to be trivial. It could also allow for the manipulation of bean to be done
> via XSLT, and other transformation mechanisms.
I totally agree with all of this!
> This should allow for the data to be transformed to/from presentation,
where
> the presentation form is itself a object model, as an analogy to the HTML
> XSLT presentation mechanism.
> Similar advantages would appertain to the storage of information, and the
> mapping of the object model to/from relational databases
>
> I must be missing something. It sounds to good. Can someone tell me what
the
> flaw in my thinking is
I think you're totally right. This was my thinking too, though I just hadn't
got far enough to actually implement this stuff - or explain it to anyone
;-)
> I would be happy to do some implementation
That would be awesome. I welcome any implementation help ;-)
As it happens, I came across a project called "JXPath" by Dmitri Plotnix
http://members-http-1.rwc1.sfba.home.net/dplotnik/jxpath/jxpath.html
What he did was do a similar binding that you suggest but bound it to W3C
DOM API. Dmitri is in the process of donating the project to the
jakarta-commons project under the name "JPath". Incidentally the
Jakarta-Commons project has some really useful code these days.
http://jakarta.apache.org/commons/index.html
Dmitri had some great ideas about allowing a kind of XMLBeanInfo type of
thing to be available per Java Bean to determine how the properties map to
Attributes and Elements. This would allow you to programatically describe
the mapping between Java Bean and XML. Just like regular BeanInfo's, the
introspector would generate one automatically.
As you suggest, a nice alternative to this mechnism would be to have some
XML document format to define this 'XMLBeanInfo' mapping, using XML rather
than Java code.
It might be that we could reuse some of this work, if we can try make it XML
object model agnostic if possible. I've CC'd Dmitri and will try bring him
up to speed on the dom4j project to see if we can all join forces on this
one - maybe having a single XML document format for the mapping and sharing
code where possible.
This all sounds very exciting Mike!
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
