Hi Aki
Hi Sergey,
i saw this mail now. I did some experiment with inTransformReader
sometime ago to do some slightly complex transformation and noticed
several things that I expected differently.
- the advancing the cursor is not done in next() but done implicitly
during the namespace lookup. Because of this, the reader can only be
used/consumed in a specific manor.
- there is no option to remove attributes
Yes
- there is no option to remove an element completely (i.e., including
its children)
One has to specify all the children of the top level element being removed,
it won't scale if the content is arbitrary/large but should work for simpler
cases.
I wanted to extend it the following way, if a given drop element value is
say {http://books}book - then drop this element only and let descendants to
stay, if {http://books}book* - drop {http://books}book and all of its
descendants.
i didn't use the stax filter to drop the elements but simply added
this deep drop logic in inTransformReader by interpreting the element
map configuraiton with an empty value to perform this deep drop.
e.g. inMap.add("{ns}value", ""} to drop the {ns}value element. I also
added the original shallow-drop logic directly in inTransformReader. I
think it's simpler to do both in one reader than layering one on the
other.
sorry, I got confused, InTransformReader (on the trunk) does support the
shallow drop of the elements via StaxStreamFilter, so supporting a deep
drop with something like inMap.add("{ns}value", ""} makes sense on the
in side. Having inReader dealing with all the drop-related code itself
can make it all a bit simpler I guess...
OutTransformReader does handle the shallow drop internally. And it can
handle the deep one using the same approach you chose for your version
of InTransformReader.
My only concern would be that the config info to do with dropping
elements will be spread across two configuration elements
(inDropElements/inTransformElements and
outDropElements/outTransformElements for shallow/deep drops) but on the
other hand no wildcards will be needed...
<
- the append option duplicates the attributes from the new child element
I see it with namespaces, yes
Not necessarily, as those namespaces are first referenced in the child
element where they are declared, their declarations need not be move
up to its parent, which is the appended element.
I saw StaxUtils doing reader.getNamespaceCount() and I was not sure how
to correctly report that in case of appended element the count is 1 :-)
So I wrote a different inTransformReader that resolve these issues. I
am wondering if I suggest it to this ticket or put it in another
ticket.
Please, open another ticket - more enhancements will be appreciated a lot.
I'm hoping to do a merge to address Andi's issue shortly and may be you can
create a patch from the trunk ?
okay.
By the way, there's one more limitation there which I haven't got to
addressing yet - to do with being able append simple elements - currently it
is possible to add wrappers but it's not possible to add a simple element
say to the end of the given element's content
We could add this feature, but is it interesting to add an empty
content element this way? I think we will probably need to provide a
way to set its content for this option, preferably filling some
content template using some runtime context values. This will likely
to require another configuraiton object.
Agreed - I meant a simple element with a text content only...
inAppendElements/outAppendElements say which elements need to be wrapped
, or rather, they say "append this element before this one".
So may be we can have
in/outAppendSimpleElements with the "append this element after this one"
message ? Say, "{http://books}id:1":"{http://books}book:title";, "add a
book ns qualified <id>1</id> after <title>...</title>"
Looks a bit btittle :-) but something along those lines
Cheers, Sergey
regards, aki
thanks, Sergey
thanks.
regards, aki
2011/7/25 Sergey Beryozkin <[email protected]>:
Sorry, forgot to mention I updated transform interceptors to accept
phase parameters, just to minimize the number of commits,
thanks, Sergey
On Sun, Jul 24, 2011 at 11:27 PM, Sergey Beryozkin <[email protected]>
wrote:
Hi Andi
On Sat, Jul 23, 2011 at 8:15 AM, akuhtz <[email protected]>
wrote:
Hi Sergey,
I've created a patch for this problem and opened
https://issues.apache.org/jira/browse/CXF-3681 CXF-3681 .
This is a good contribution, thanks.
I've applied most of the patch (DelegatingNamespaceContext fix plus
all the new tests) but I had to omit the actual fix for
InTransformReader
given that the tests in rt/frontend/jaxrs started failing
(JAXBElementProvider tests which do rely on the same transform
feature).
InTransformReader can also handle appending or rather wrapping certain
in elements, example,
<book><name>CXF</name></book>
can be wrapped with say a 'books' element
<books><book><name>CXF</name></book></books>
At the moment, calling resetCurrentQName in next() 'upsets' some of
the tests. Perhaps a simpler reset can be done for your case to start
working but it's difficult for me to investigate without a failing
test - all of the new tests still pass without this update.
I think the complete fix is nearly there :-). For example, configure
InTransformReader with appendMap too and then you can reproduce the
failure.
Thanks, Sergey
Cheers,
Andi
--
View this message in context:
http://cxf.547215.n5.nabble.com/Problem-with-new-transform-feature-tp4599185p4625533.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com
