commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Ferris <>
Subject Re: Betwixt : flavours for complex objects
Date Tue, 08 Nov 2005 08:48:18 GMT
So I'd like to toss my two cents in on the issue.  I was recently  
working with a custom IdStoringStrategy which used an Option value to  
determine if an instance of an object would be encoded with an id-ref  
or not.  Something like:

   <element name="node" property="node">

I quickly discovered that things didn't work quite as I planned,  
since the Conext object passed into method calls in IdStoringStrategy  
didn't have any Options.  The relevant code in AbstractBeanWriter  
indicated that options weren't pushed onto the context stack prior to  
calls concerning the id-storage strategy.  I patched  
AbstractBeanWriter to push options onto the stack at the appropriate  
point, but I still wasn't getting the behavior I wanted.  It boils  
down to the "option inheritance" that Robert was hinting at.  When I  
pushed the options onto the stack, I had a choice of the options from  
the ElementDescriptor defined by the parent class (options of the  
"node" element in the above example) or options from the  
ElementDescriptor defined by the target node class (options  
potentially defined in a .betwixt file for the underlying node class).

Ultimately, I chose a solution that combined the two sets of options,  
allowing the Options in the parent to override the Options in the  
target class.  I think that behavior works best since it allows you  
to define default Options in the target class and then override them  
as needed in parent classes for custom rendering.  I know my use of  
parent and target probably isn't the properly terminology here, but  
hopefully you get the idea.

Anyways, I'd like to see behavior like this incorporated and I'm  
willing to write up a patch if something can be agreed to.

Brian Ferris

On Nov 2, 2005, at 3:06 PM, robert burrell donkin wrote:

> On Tue, 2005-11-01 at 07:58 -0600, Ryan McGuinness wrote:
>>> I have an issue with objects and flavours, and need to know where to
>>> look. I have read the docs, and the source, at this point it  
>>> still is
>>> unclear.
>>> I have two objects
>>> public Object1 {
>>> 	private String name;
>>> 	Object2 property1 = new Object2();
>>> 	...
>>> }
>>> public Object2 {
>>> 	private String attr1;
>>> 	private String attr2;
>>> }
>>> in my .betwixt file, I have a definition:
>>> object1.betwixt
>>> <info>
>>> 	<element name='my-first-object'>
>>> 		<element name='my-name' property='name'>
>>> 			<option>
>>> 				<name>value</name>
>>> 				<value>myValue</value>
>>> 			</option>
>>> 		</element>
>>> 		<element name='my-object' property='property1'>
>>> 			<option>
>>> 				<name>value</name>
>>> 				<value>mySecondValue</value>
>>> 			</option>
>>> 		</element>
>>> 	</element>
>>> </info>
>>> I have written a custom StringConverter, and I can see which  
>>> flavours
>>> are being passed, and which are not.
>>> basically, I do not get a flavour when I am calling the complex type
>>> (property1).
> as the code stands now, this is expected.
>>> Do I have to create a ClassConverter? or do I have to modify some  
>>> base
>>> class? or is there a plugable approach that I can take for this.
> not ATM. probably need to add some kind of option inheritance for this
> use case.
> options are posted onto a stack. ATM only access to the top of the  
> stack
> is possible. probably need to be able to access options down the  
> stack.
> it would be easy (and backwards compatible) to add a method to context
> that searched the stack and returned the first option value matching a
> particular name.
> opinions?
>>> I need a flavour for this custom object because in one output I  
>>> have to
>>> create:
>>> <my-object attr1='somevalue' />
>>> and in another
>>> <my-object>
>>> 	<attr1>value1</attr1>
>>> 	<attr2>value2</attr1>
>>> </my-object>
> this is a structural change
> i think that the quickest way to get this working would be to use
> multi-mappings
> (
> 20Mapping). for each output type, define the mappings for object  
> one and
> object two within the same multi-mapping.
> if you are caching XmlBeanInfo's then you'll need to maintain a  
> separate
> registry for each mapping.
> - robert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message