Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v623)
Content-Transfer-Encoding: 7bit
Message-Id: <12ad8943989836e84d9e137fbf15cbcc@robinwyles.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: dev@cocoon.apache.org
From: Robin Wyles <rob@robinwyles.com>
Subject: RepeaterJXPathBinding
Date: Tue, 6 Dec 2005 12:02:52 +0100

Hi All,

Up until recently I was able to have a repeater binding like this...

<fb:repeater id="repeater" parent-path="." row-path="collection">
	<fb:identity>
		<fb:value path="id" id="id" />
	</fb:identity>
	<fb:on-bind>
		[...]
	</fb:on-bind>
	<fb:on-delete-row>
		<fb:delete-node />
	</fb:on-delete-row>
</fb:repeater>

This would handle the loading, updating and deleting of rows in the  
repeater, but ignore newly added rows. This was neat because it meant I  
could use a second custom binding to handle the binding for newly added  
rows thus allowing me to bind collections containing objects of  
different classes.

However after revision 349806 of RepeaterJXPathBinding.java this usage  
results in...

org.apache.commons.jxpath.JXPathException: Cannot create a relative  
context for a non-existent node: /collection[8]
at  
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getRelativeConte 
xt(JXPathContextReferenceImpl.java:581)
	at  
org.apache.cocoon.forms.binding.RepeaterJXPathBinding.doSave(RepeaterJXP 
athBinding.java:253)
[...]

Comparing this revision with the previous one I can see why the error  
is occurring - in the previous revision the new row context is not  
created if the insert binding does not exist, this is not the case in  
the latest revision. I've patched my copy which continues to work as  
expected for normal repeater bindings and my binding as outlined above.  
However I don't know enough about the binding framework to know if this  
change between the last revision was for a specific reason and whether  
my patch to revert the behaviour will break other things. Can someone  
take a look?

Thanks,

Robin