You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Ryan McGuinness <ry...@fallingonline.com> on 2005/11/01 14:58:53 UTC
Betwixt : flavours for complex objects
> 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).
>
> 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.
>
> 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>
>
> Please let me know as soon as possible.
>
> Thanks,
> Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Betwixt : flavours for complex objects
Posted by Brian Ferris <bd...@cs.washington.edu>.
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">
<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).
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.
Thanks,
Brian
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
> (http://jakarta.apache.org//commons/betwixt/guide/binding.html#Multi%
> 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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: Betwixt : flavours for complex objects
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: Betwixt : flavours for complex objects
Posted by Brian Ferris <bd...@u.washington.edu>.
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">
<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).
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.
Thanks,
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
> (http://jakarta.apache.org//commons/betwixt/guide/binding.html#Multi%
> 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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
Re: Betwixt : flavours for complex objects
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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
(http://jakarta.apache.org//commons/betwixt/guide/binding.html#Multi%
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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org