commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Betwixt : flavours for complex objects
Date Tue, 08 Nov 2005 20:53:40 GMT
On Tue, 2005-11-08 at 00:48 -0800, Brian Ferris wrote:
> So I'd like to toss my two cents in on the issue.  

grand :)

> 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">
>      <option>
>        <name>use-idref</name>
>        <value>true</value>
>      </option>
>    </element>
> 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).

i added a new method getInheritedOption() recently to context that
searches the options stack for the first match. this has some drawbacks
(in that it doesn't completely address the issue) but was quick to code
and is useful in some use cases.

opinions welcomed :)

> 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.

i'm not sure there really is any standard terminology but i think i know
what you mean. a property mapped to a complex type in the schema is
modelled in the descriptors by a hollow descriptor in the property. the
filled descriptor for the class is pushed onto the stack but ignored (in
many ways). 

in a lot of ways, parent property and target type are as reasonable
terms as any for this arrangement (so with any luck) they might be
adopted ;)

this causes difficulties with options since options for the target type
are pushed onto the stack and so override those of the parent. this is
(at best) unintuitive.

> 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.

i like patches :)

but the question is: what's the best approach. 

ignoring target options is intuitive but breaks semantic compatibility.
(not to say that this would be a reason to reject the idea, just needs a
little consideration). 

(as always) opinions welcomed 

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message