Hi László!

If you supply values for @at and @position, you can override the default 
behaviour of xf:insert to control where the insertion is made. The 
relevant documentation is here: http://www.w3.org/TR/xforms11/#action-insert

I have done this before but I don't have the worked example to hand; I 
hope this is correct though:

If you want your insertion to be made after any <ch1> and <ch2> 
elements, you might use @at="count(ch1) + count(ch2)" and 
@position="after". Or you could insert before any <ch4> or <ch5> 
elements, using @at="size() - count(ch4) - count(ch5)" and 
@position="before".

I hope that helps!

Conal


On 05/06/12 19:21, sores wrote:
> Hi All,
>
> When inserting new elements into an empty repeat the context attribute
> has to be used to define the insert location. By default the inserted
> element will be positioned after the last child of the context nodeset.
> Is there a way to control this behaviour?
> (for example an axis xpath attribute somewhere that would define the
> insertion point in the context node)
>
> I am trying to build web interfaces for fairly complex XSD schema
> defined objects with lots of optional elements. In an XML instance these
> optional elements may not be present. When someone starts to add them
> they appeare in a wrong location and make XSD validation fail. Having
> empty optional elements in the XML instances would work, but | wanted to
> avoid this.
>
> An easy way to solve the problem is reordering the elements with an xsl
> transformation. Before doing so I would like to know if I am missing
> something obvious.
>
> Best regards,
>
> László Sőrés


-- 
Conal Tuohy
eResearch Business Analyst
Victorian eResearch Strategic Initiative
+61-466324297


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Xsltforms-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Reply via email to