You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2012/01/25 23:19:07 UTC
Transform Feature Improvements (Was: Re: svn commit: r1227691)
Hi Aki
I've changed the subject, hope you are ok with it
On 25/01/12 10:04, Aki Yoshida wrote:
> 2012/1/24 Sergey Beryozkin<sb...@gmail.com>:
>> Hi Aki
>>
>> On 05/01/12 16:49, ay@apache.org wrote:
>>>
>>> Author: ay
>>> Date: Thu Jan 5 16:49:56 2012
>>> New Revision: 1227691
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1227691&view=rev
>>> Log:
>>> [CXF-4013] Enhancing the element-append and drop options of
>>> OutTransformWriter
>>>
>>
>> I've finally updated the documentation [1] to take note of your enhancement,
>> thanks for this fine effort.
>>
>> It's quite complete now, this feature, may be we can offer some basic
>> conditional transformation support in time too :-)
>>
>
> Hi Sergey,
>
> Thanks for the documentation update. We have now the inbound and
> outbound transformation features aligned.
>
> Yes, we can add a few things along this transformation model. Allowing
> a simple node path rather than just its node name to pick the node is
> a useful extension. This will be easy. Providing some conditional
> transformation is also useful one. If we can limit its functionality
> and complexity in some reasonably level, that will be good.
>
I thought briefly about it, supporting node paths and simple conditions
can probably be handled at the same time.
As far as the condition is concerned, it should probably be
straightforward conditions such as:
/a:bar/a:foo = "text"
/a:bar/a:foo/@baz = "text"
and say inTransformMap:
/a:bar/a:foo : {myns2}foo
I recall you had an idea how to specify prefixes, may be we can also set
a custom namespaceToPrefixes map so that we can say:
/a:bar/a:foo : {b}foo
at any moment of time we can get String or some stack pointing to the
current simple element or attribute.
If no conditions are there then as soon as we get a matching path we
apply the transfpormation, otherwise we additionally check that the
simple conditions are met
I guess we can do something not too over-complex indeed, in many cases
it's probably simple logic or path that can be applied
Cheers, Sergey
> Regards, aki
>
>> Cheers
>> Sergey
>>
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/CXF20DOC/TransformationFeature
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Transform Feature Improvements (Was: Re: svn commit: r1227691)
Posted by Aki Yoshida <el...@googlemail.com>.
2012/1/26 Sergey Beryozkin <sb...@gmail.com>:
> Hi,
>
>
> On 26/01/12 09:52, Aki Yoshida wrote:
>>
>> 2012/1/25 Sergey Beryozkin<sb...@gmail.com>:
>>>
>>> Hi Aki
>>>
>>> I've changed the subject, hope you are ok with it
>>>
>>> On 25/01/12 10:04, Aki Yoshida wrote:
>>>>
>>>>
>>>> 2012/1/24 Sergey Beryozkin<sb...@gmail.com>:
>>>>>
>>>>>
>>>>> Hi Aki
>>>>>
>>>>> On 05/01/12 16:49, ay@apache.org wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Author: ay
>>>>>> Date: Thu Jan 5 16:49:56 2012
>>>>>> New Revision: 1227691
>>>>>>
>>>>>> URL: http://svn.apache.org/viewvc?rev=1227691&view=rev
>>>>>> Log:
>>>>>> [CXF-4013] Enhancing the element-append and drop options of
>>>>>> OutTransformWriter
>>>>>>
>>>>>
>>>>> I've finally updated the documentation [1] to take note of your
>>>>> enhancement,
>>>>> thanks for this fine effort.
>>>>>
>>>>> It's quite complete now, this feature, may be we can offer some basic
>>>>> conditional transformation support in time too :-)
>>>>>
>>>>
>>>> Hi Sergey,
>>>>
>>>> Thanks for the documentation update. We have now the inbound and
>>>> outbound transformation features aligned.
>>>>
>>>> Yes, we can add a few things along this transformation model. Allowing
>>>> a simple node path rather than just its node name to pick the node is
>>>> a useful extension. This will be easy. Providing some conditional
>>>> transformation is also useful one. If we can limit its functionality
>>>> and complexity in some reasonably level, that will be good.
>>>>
>>>
>>> I thought briefly about it, supporting node paths and simple conditions
>>> can
>>> probably be handled at the same time.
>>> As far as the condition is concerned, it should probably be
>>> straightforward
>>> conditions such as:
>>>
>>> /a:bar/a:foo = "text"
>>> /a:bar/a:foo/@baz = "text"
>>>
>>> and say inTransformMap:
>>> /a:bar/a:foo : {myns2}foo
>>>
>>> I recall you had an idea how to specify prefixes, may be we can also set
>>> a
>>> custom namespaceToPrefixes map so that we can say:
>>> /a:bar/a:foo : {b}foo
>>>
>>> at any moment of time we can get String or some stack pointing to the
>>> current simple element or attribute.
>>>
>>> If no conditions are there then as soon as we get a matching path we
>>> apply
>>> the transfpormation, otherwise we additionally check that the simple
>>> conditions are met
>>>
>>> I guess we can do something not too over-complex indeed, in many cases
>>> it's
>>> probably simple logic or path that can be applied
>>
>>
>> Hi Sergey,
>>
>> If the conditions can be evaluated at the time of parsing, we can keep
>> the mechanism simple. So, we should assume this restriction.
>>
>> Regarding how to specify the fixed namespace prefixes, for the plain
>> bean property based configuration, we could provide a namespace-prefix
>> mapping table. But this is kind of redundant because the namespace
>> prefix binding is in the parsing context. I wonder if there is a
>> simple way to get to the underlining namespace context without
>> introducing a spring/BP namespace handler for this feature. If not, we
>> can start with the mapping table approach.
>>
>
> I was not thinking of introducing a spring or BP handler, but rather
> optionally providing a namespace mapping table to the in/out writers.
> I'm not sure that the prefix that JAXB will provide at a given time will
> always match the one specified in the path/condition.
>
> May be the first step, before even trying to deal with paths or conditions,
> is to start supporting transform maps such as:
>
> "a:b" to "a1:b"
>
> as an alternative to
>
> "{http://myns/1}b" to "{http://myns/2}:b"
>
> which will be possible if the additional table is available with
> http://myns/1: a
> http://myns/2: a1
>
> values...
>
>
> I may give it a try a bit later on if you agree it makes sense
Sounds good. That will be fine with me. So I suppose, we will have
something like
<property name="outTransformElements">
<map>
<entry key="a:b" value="a1:b"/>
...
</map>
</property>
<property name="namespaces" >
<map>
<entry key="a" value="http://myns/1"/>
<entry key="a1" value="http://myns/2"/>
</map>
</property>
regards, aki
>
> Cheers, Sergey
>
>
>
>> regards, aki
>>
>>>
>>> Cheers, Sergey
>>>
>>>> Regards, aki
>>>>
>>>>> Cheers
>>>>> Sergey
>>>>>
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/CXF20DOC/TransformationFeature
>>>
>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>
>>> Blog: http://sberyozkin.blogspot.com
Re: Transform Feature Improvements (Was: Re: svn commit: r1227691)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 26/01/12 09:52, Aki Yoshida wrote:
> 2012/1/25 Sergey Beryozkin<sb...@gmail.com>:
>> Hi Aki
>>
>> I've changed the subject, hope you are ok with it
>>
>> On 25/01/12 10:04, Aki Yoshida wrote:
>>>
>>> 2012/1/24 Sergey Beryozkin<sb...@gmail.com>:
>>>>
>>>> Hi Aki
>>>>
>>>> On 05/01/12 16:49, ay@apache.org wrote:
>>>>>
>>>>>
>>>>> Author: ay
>>>>> Date: Thu Jan 5 16:49:56 2012
>>>>> New Revision: 1227691
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1227691&view=rev
>>>>> Log:
>>>>> [CXF-4013] Enhancing the element-append and drop options of
>>>>> OutTransformWriter
>>>>>
>>>>
>>>> I've finally updated the documentation [1] to take note of your
>>>> enhancement,
>>>> thanks for this fine effort.
>>>>
>>>> It's quite complete now, this feature, may be we can offer some basic
>>>> conditional transformation support in time too :-)
>>>>
>>>
>>> Hi Sergey,
>>>
>>> Thanks for the documentation update. We have now the inbound and
>>> outbound transformation features aligned.
>>>
>>> Yes, we can add a few things along this transformation model. Allowing
>>> a simple node path rather than just its node name to pick the node is
>>> a useful extension. This will be easy. Providing some conditional
>>> transformation is also useful one. If we can limit its functionality
>>> and complexity in some reasonably level, that will be good.
>>>
>>
>> I thought briefly about it, supporting node paths and simple conditions can
>> probably be handled at the same time.
>> As far as the condition is concerned, it should probably be straightforward
>> conditions such as:
>>
>> /a:bar/a:foo = "text"
>> /a:bar/a:foo/@baz = "text"
>>
>> and say inTransformMap:
>> /a:bar/a:foo : {myns2}foo
>>
>> I recall you had an idea how to specify prefixes, may be we can also set a
>> custom namespaceToPrefixes map so that we can say:
>> /a:bar/a:foo : {b}foo
>>
>> at any moment of time we can get String or some stack pointing to the
>> current simple element or attribute.
>>
>> If no conditions are there then as soon as we get a matching path we apply
>> the transfpormation, otherwise we additionally check that the simple
>> conditions are met
>>
>> I guess we can do something not too over-complex indeed, in many cases it's
>> probably simple logic or path that can be applied
>
> Hi Sergey,
>
> If the conditions can be evaluated at the time of parsing, we can keep
> the mechanism simple. So, we should assume this restriction.
>
> Regarding how to specify the fixed namespace prefixes, for the plain
> bean property based configuration, we could provide a namespace-prefix
> mapping table. But this is kind of redundant because the namespace
> prefix binding is in the parsing context. I wonder if there is a
> simple way to get to the underlining namespace context without
> introducing a spring/BP namespace handler for this feature. If not, we
> can start with the mapping table approach.
>
I was not thinking of introducing a spring or BP handler, but rather
optionally providing a namespace mapping table to the in/out writers.
I'm not sure that the prefix that JAXB will provide at a given time will
always match the one specified in the path/condition.
May be the first step, before even trying to deal with paths or
conditions, is to start supporting transform maps such as:
"a:b" to "a1:b"
as an alternative to
"{http://myns/1}b" to "{http://myns/2}:b"
which will be possible if the additional table is available with
http://myns/1: a
http://myns/2: a1
values...
I may give it a try a bit later on if you agree it makes sense
Cheers, Sergey
> regards, aki
>
>>
>> Cheers, Sergey
>>
>>> Regards, aki
>>>
>>>> Cheers
>>>> Sergey
>>>>
>>>>
>>>> [1]
>>>>
>>>> https://cwiki.apache.org/confluence/display/CXF20DOC/TransformationFeature
>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
Re: Transform Feature Improvements (Was: Re: svn commit: r1227691)
Posted by Aki Yoshida <el...@googlemail.com>.
2012/1/25 Sergey Beryozkin <sb...@gmail.com>:
> Hi Aki
>
> I've changed the subject, hope you are ok with it
>
> On 25/01/12 10:04, Aki Yoshida wrote:
>>
>> 2012/1/24 Sergey Beryozkin<sb...@gmail.com>:
>>>
>>> Hi Aki
>>>
>>> On 05/01/12 16:49, ay@apache.org wrote:
>>>>
>>>>
>>>> Author: ay
>>>> Date: Thu Jan 5 16:49:56 2012
>>>> New Revision: 1227691
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1227691&view=rev
>>>> Log:
>>>> [CXF-4013] Enhancing the element-append and drop options of
>>>> OutTransformWriter
>>>>
>>>
>>> I've finally updated the documentation [1] to take note of your
>>> enhancement,
>>> thanks for this fine effort.
>>>
>>> It's quite complete now, this feature, may be we can offer some basic
>>> conditional transformation support in time too :-)
>>>
>>
>> Hi Sergey,
>>
>> Thanks for the documentation update. We have now the inbound and
>> outbound transformation features aligned.
>>
>> Yes, we can add a few things along this transformation model. Allowing
>> a simple node path rather than just its node name to pick the node is
>> a useful extension. This will be easy. Providing some conditional
>> transformation is also useful one. If we can limit its functionality
>> and complexity in some reasonably level, that will be good.
>>
>
> I thought briefly about it, supporting node paths and simple conditions can
> probably be handled at the same time.
> As far as the condition is concerned, it should probably be straightforward
> conditions such as:
>
> /a:bar/a:foo = "text"
> /a:bar/a:foo/@baz = "text"
>
> and say inTransformMap:
> /a:bar/a:foo : {myns2}foo
>
> I recall you had an idea how to specify prefixes, may be we can also set a
> custom namespaceToPrefixes map so that we can say:
> /a:bar/a:foo : {b}foo
>
> at any moment of time we can get String or some stack pointing to the
> current simple element or attribute.
>
> If no conditions are there then as soon as we get a matching path we apply
> the transfpormation, otherwise we additionally check that the simple
> conditions are met
>
> I guess we can do something not too over-complex indeed, in many cases it's
> probably simple logic or path that can be applied
Hi Sergey,
If the conditions can be evaluated at the time of parsing, we can keep
the mechanism simple. So, we should assume this restriction.
Regarding how to specify the fixed namespace prefixes, for the plain
bean property based configuration, we could provide a namespace-prefix
mapping table. But this is kind of redundant because the namespace
prefix binding is in the parsing context. I wonder if there is a
simple way to get to the underlining namespace context without
introducing a spring/BP namespace handler for this feature. If not, we
can start with the mapping table approach.
regards, aki
>
> Cheers, Sergey
>
>> Regards, aki
>>
>>> Cheers
>>> Sergey
>>>
>>>
>>> [1]
>>>
>>> https://cwiki.apache.org/confluence/display/CXF20DOC/TransformationFeature
>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com