Hi, Venkata.
Please see my comments below.
Thanks,
Raymond
----- Original Message -----
From: "Venkata Krishnan" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, September 25, 2006 2:52 AM
Subject: Re: Queries related to Component Property Loading
Hi Jeremy, Raymond,
Hi Jeremy / Raymond,
- Here is what I propose to do w.r.t. Component Properties
1) I have added a new attribute called 'override' to capture the override
options and have defined three constants 'must', 'may', 'no' that can be
set
to this attribute. I have done away with the attribute called 'required'
"required" seems to be from the java @Property annotation. How is it related
to "override"?
2) In the component loader, during the property loading phase...
- PropertyValue objects will be created only if the corresponding
Property's
'override' attribute is either 'may' or 'must'. It it is 'no', an
exception
will be thrown.
Yes.
- After all properties defined in the scdl have been loaded, the list of
properties in the component type will be checked to see if there is any
property who 'override' attribute is 'must' and is not defined as part of
the component defn. If there exists one then an exception is thrown
I think this validation step can only be done at "build" phase, right?
- I understand that the value of component properties will also be defined
as xml similar to how the default values are defined in the component type
file i.e. property values will also be xml document fragments
The current code doesn't handle the property value correctly. The SCA spec
defines the following syntax:
<property name="xs:NCName" source="xs:string"? file="xs:anyURI"?>*
property-value
</property>
The spec takes the order as "source", "file" and content-value.
The property value will represented by a DOM Document which can be evaluated
against the composite property by XPath, loaded from the file URI, or parsed
from the current StAX reader. Can the XPath evaluation be done at "load"
phase? I have the code for the XPath part.
- Each property has an xml type specified, but where do we locate the
xsd for this type?
Maybe we can start with "xsi:schemaLocation". By the spec, the "type" is
required. Should we add an attribute to @Property for xmlType? For simple
types, we can use Java2XML mapping in SimpleTypeMapperExtension.
The current code uses "StAXPropertyFactory" to create the target property
value (for simple types). I have created a Databinding-based property
factory which knows how to create the value out of the DOM Document.
- The property value as an xml document will be passed to the
ComponentBuilders (js component builder, ruby component builder...) which
will handle the logic of transforming them into data forms that can be
injected into the implementations (javascript, rubyscript...).
I'm thinking of adding the following "build" logic to
ComponentBuilderExtension.
For each property in the component type, we either use the default value
(override="no" or override="may" but no property value is found), or the
configured value from the property value (override="must" or override="may"
and a matching property is found) to create an instance of ObjectFactory
which knows how to transform the DOM Node into the target type using our
DataBinding support).
The JavaComponentBuilder will inject the property values into the target
POJO instance. Other component builders may have their own way to pass
properties to their implementations.
Am I on track with this?
Thanks
- Venkat
On 9/20/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
Hi Raymond,
I will be out of town tomorrow on some pressing personal work and will be
back on Friday. When I am back I will set on to this with lots of help
from
you ;-). Thanks.
- Venkat
On 9/19/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> Couple of comments inline - I'll leave other areas to Raymond.
>
> On Sep 19, 2006, at 10:54 AM, Venkata Krishnan wrote:
>
> > 1) I find that the DefaultValue in the class Property is supposed
> > to be
> > present as a Document instance.
>
> > //Added by Venkat for this mail : should the following line
> > be added
> > to fix this problem.
> > doc.appendChild(root);
>
> > Is this a right fix? Otherwise what am I missing here?
>
> Seems reasonable.
>
> >
> > 2) Assuming the DefaultValue is available in its Document form in the
> > implementation (say javascript or ruby container impl), I would
> > need to
> > convert it to Java Object and from it to data that javascript /
> > ruby can
> > understand. I imagine that I must be using the DataBinding
> > framework /
> > service here for this conversion. How will this be made available
> > to the
> > implementation - as a autowired service or just as framework whos
> > classes I
> > must instantiate and use appropriately? Is there a transformer in
> > the
> > databinding framework to convert between Document to Java
> > (something like
> > OMElement2Java or Java2OMElement) ?
>
> I would think the builder would autowire to the framework somehow.
> Raymond, any details?
>
> >
> > 3) In the ComponentLoader where PropertyValue instances are created
> > (as a
> > result of property specification in the component defn) why can't
> > it be that
> > 'PropertyValue' instances are first created for all 'Property'
> > instances as
> > found in the componentType. Then the values are set either to
> > whatever is
> > specified for value in the component definition or to whatever is
> > available
> > in 'DefaultValue' attribute of the Property class. So, when the
> > component
> > builders are called, the component defn. instances that are passed
> > will be
> > already populated with property values. Is this thinking right?
>
> I was thinking the builder would just look for the PropertyValue
> first and then if nothing was specified go to the default. That
> avoids copying the values, and allows for the case where the value is
> totally undefined ( e.g. optional with no default).
>
> > Again over
> > here, to convert the values specified in the component defns. I
> > guess we
> > should employ the databinding framework - right?
>
> Yes.
>
> >
> > 4) In the current implementation of ComponentLoader, while create a
> > PropertyValue the 'JavaType' attribute of the property seems to be
> > required
> > so that the right object factories can be created. However this
> > JavaType
> > attribute is never set and this results in a NPE. I guess if the
> > databinding framework is going to be used here to convert Document
> > data to
> > java objects this problem would be resolved - is this right?
>
> The ComponentLoader still needs to be converted to using the DOM form
> and have all the xpath stuff added. I think this is just a bug that
> should go away when these changes are made. I don't think anyone is
> working on that.
>
> >
> > 5) Finally (if you have managed to bear with me until this
> > point :)), why is
> > it that I must deal with an object factory to get a property
> > value. Can I
> > not be allowed to simply access it as ' propertyValue.getValue()'.
> > Now it
> > seems like I must do a propertyValue.getValueFactory().getInstance
> > () to get
> > the value of a property. Why?
>
> Because the value may need to be injected multiple times which may
> involve creating different instances of it to avoid aliasing bugs.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> 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]
