Hi,
On 26/01/12 09:52, Aki Yoshida wrote:
2012/1/25 Sergey Beryozkin<[email protected]>:
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<[email protected]>:
Hi Aki
On 05/01/12 16:49, [email protected] 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
