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]
