[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    RE: beaninfo editor support
From:       "Mike Skells" <Mike.Skells () ebizz-consulting ! com>
Date:       2004-04-18 21:42:59
Message-ID: 008701c4258e$2146ac40$0100a8c0 () mikework
[Download RAW message or body]



> -----Original Message-----
> From: David Remy [mailto:dremy@bea.com] 
> 
> 
> Mike Skells wrote:
> > Hi,
> > I was looking at the feature proposals, but I saw no mention of
> > support for full javabean features such as property editors class,
> > descriptions etc  
> 
> Yep you are right.  There is not a feature proposal for full 
> javabean features right now.  I have to confess I don't know 
> a lot about javabeans or how valuable it would be if 
> generated classes conformed as much as possible by having 
> these above features.  In the V2 there are two binding 
> styles, one in which the generated interfaces/classes extend 
> XmlObject which allows the java type hierarchy to mirror the 
> XML schema Type heirarchy.  These classes do not have a 
> zero-arg constructor, which is a requirement for a javabean, 
> correct?  The second binding style which is JAX/RPC binding 
> does create plain old java classes so it may work better for 
> this use case.
Javabeans, and serialisation do both require zero arg constructor. I
would think that serialisation would be considered as a use case would
it?

For my purposes the zero arg issue is not a problem really. 
What I need to do is be able to derive behaviour from the introspection
process and the associated beaninfo derived behaviours

I would need a mechanism to determine the XMLBean classes inheritance
structure, and for the other work it would be useful to keep the XML
inheritance structure is step with the java structure, so I think that
the second version might be more appropriate

What is the proposed timescale for V2?

I presume that there is a mechanism to control and extend the code
production mechanism, that I could tap into and contribute.

The advantage that I see from the javabeans structure is that the
XMLBeans would interwork with other systems. E.g.

JSTL - the expression language delivered in JSP2.0 allows you to write
javascript style expression that can operate against jaa objects. These
libararies can also be used outside JSP code as a general expression
language. We use this is current commercial products. There are
facilities to also interwork against a W3C DOM model with Xpath support,
but this is weaker IMHO. 

Visual editing - The javabean structure could provide the mechanism for
a simple and automatic view of a document (this is the feature that I
need), where the nodes in a document can be provided as a Jtree, and
focussing on a node updates a property window, like a normal IDE. If the
beaninfo class can be provided then the property editors can be
currently configured, prompts, help, title, internationalisation, and
(for me the most important features) the property editor.
If you consider the case where a value is constained by a key/value XSD
constrainst, the editor could provide a listbox with the acceptable
value.

Long term serialisation - (I havent used it but I believe) works on bean
patterns (but will also probably need a zero arg constructor, but maybe
a private one wil be OK like normal serialisation)
 
> 
> > 
> > Is there an ability to generate the beans in 2 forms, one read only
> > (for config files use) and one read write, with property listener
> > support etc (for design time)  
> 
> Not in a straightforward way yet.  In V1 there is no support 
> for this.  
> 
> In V2 Cezar is experimenting with the ability to provide pre- 
> and post- methods that will be called before and after 
> getters and setters (which would be property changes?).  In a 
> pre- method you can return false and the target call will not 
> be done.  You could use this to essentially have read-only by 
> returning false on all of the setters or adds.

This looks like property change, and vetoable property change. Within
the JB framework there are support classes to aid this implementation,
and provide information as the whethere the property values are
constrained. In this model the chnages are vetoed which generates an
exception rather than a boolean, and therefore can contain more
information as to why it failed

> 
> > 
> > Forgive me if this is already present or in plan - I am usable to
> > build from CVS currently (a local problem) and awaiting the release
> > build and docs!  
> > 
> > I am particually interested in being able to view and edit the
> > properties in an IDE using property editors, where some of the
> > constraints are in the XML but others cannot be expressed in the XSD
> > form and need additional code   
> 
> Another feature that Cezar is working on is the ability to 
> provide the schema compiler with an interface and an 
> implementation.  The interface methods will be implemented in 
> the target generated class(es) and call back your implementation.

This would also provide some other uses, I presume that the
implementation classes could inherit from the generated classes, and
provide that additional behaviours and or constraints. We have
experience with this generation structure for generated SQL / java
template code generation (used in internal tools), and the structur that
we use for that is a little more complex, with some interfaces and
classes  being fully template generated, and others generating user
extensible classes. I believe that the same model should work here (this
was one avenue that we briefly explored a while ago)

> 
> These feature were not really designed with beaninfo support 
> in mind.  It would be interesting to know what we could do 
> have the the XMLBeans generated classes meet this kind of need.

It certainly seems that there are a wealth of possibilities. I think
that major issues wil be looking at the timescales, and the amount of
additional development that is required against the pressures current
projects, and the complexity of development. All things being equal I
would hope to be able to make some contribution. It 'feels' the right
solution to solve a few problems that we have, so if the detail checks
out I would like to incorperate this in a development slated for late
this year, and also one of the internal tools that we use.

Mike

> 
> rem
> > 
> > Yours hopefully
> > Mike Skells
> > eBizz Consulting
> 



- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

[prev in list] [next in list] [prev in thread] [next in thread]