I'll give a try.
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 18, 2006 7:10 PM
Subject: Re: Data binding extensions and changes to the SCA spec
On Jul 18, 2006, at 5:28 PM, Raymond Feng wrote:
Hi,
It should be a good fit to use Transfomation service to present
property values in a preferred way indicated by the property receiver.
Here're some use cases I can imagine:
1) Parse the XML for a property value to create a DOM
representation (StAX XMLStreamReader-->DOM Node)
2) Inject the property to the target instance:
For example,
@DataBinding(type="sdo", ...)
@Property
private MyProperty myProperty;
We could support the annotation but I was also thinking we could have
a Tuscany runtime configuration set per component implementation
type. I like the configuration approach with an attribute override
since it allows implementation code to remain agnostic of the
databinding unless it needs something specific (in which case it
could use the annotation).
Raymond, do you want to take a stab at separating packages into what
should go into an SPI and what should go into core?
Jim
Then DOM Node --> SDO DataObject can be applied.
Thanks,
Raymond
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 18, 2006 2:12 PM
Subject: Data binding extensions and changes to the SCA spec
I would like to get started on support for for XPath in SCDL as it
is part of the recent SCA spec changes. This will likely require
changes to the loader infrastructure and in particular
StringParserPropertyFactory. Instead of having a PropertyFactory
create an ObjectFactory responsible for returning a value that is
injected into a component implementation instance, we will need
to have a more flexible approach as property values may now be
based off of XPath expressions to composite properties.
What I would like to propose is that we have creation of the
ObjectFactory for the property handled by the builder in much the
same way as it handles wires. I think we can leverage the data
transformation service for this. In this case, the builder will
be given a representation of the parsed XML, probably DOM. If
the property value was an XPath expression, the builder will have
to use an XPath engine to evaluate and retrieve this actual value
(Jaxen?) represented as a Node. The builder will then in turn use
the transformation service to create a "bound type". The builder
will subsequently create an ObjectFactory for the bound type
responsible for injecting on the target component implementation
instance. The specific kind of ObjectFactory will depend on the
kind of property it is:
- If it is immutable, the builder will use a SingletonObjectFactory
- If it is mutable, but the property is configured as
"safe" (i.e. the component does not mutate it), the builder will
use a SingletonObjectFactory). We can also assume by default
values are "safe" unless explicitly marked.
- If it is mutable, marked "not safe," and Cloneable, a
CloningObjectFactory is used which clones on getInstance()
-If it is mutable, marked "not safe" and is not Cloneable, the
builder avoids the call to the transformation service and instead
uses an ObjectFactory which calls out the to transformation
service on every getInstance() invoke.
For some implementation types, a builder may not want to use
ObjectFactory (perhaps the implementation just takes a DOM or
some other format). In that case, the builder would be free to
use the transformation service or not.
Raymond, does this sound like it would fit with the transformation
service? If so, I think we need to look at incorporating the base
data transformation framework into SPI and core.
I'd also be willing to work on an XStream binding extension which
would enable handling of basic POJO binding.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
