cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: persisting re-arranged repeater-rows
Date Wed, 26 Nov 2003 21:15:31 GMT
Marc Portier wrote:

>
> Jeremy Quinn wrote:
>
>>
>> On 25 Nov 2003, at 23:18, Sylvain Wallez wrote:
>>
>>> Bruno Dumon wrote:
>>>
>>>> On Tue, 2003-11-25 at 13:47, Jeremy Quinn wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I am struggling with persisting re-arranged repeater rows.
>>>>>
>>>>> I have a form that edits an Album Bean which has a 
>>>>> (java.util.List) 'Resources' Property which is populated by 
>>>>> Resource Beans.
>>>>>
>>>>> I have the List of Resource Beans represented in the form as a 
>>>>> repeater-widget, with move-up, move-down buttons.
>>>>>
>>>>> When I click one of the up/down buttons, the repeater-rows get 
>>>>> re-arranged correctly in the form.
>>>>>
>>>>> When I save the Album (I am using Hibernate, with cascading) the 
>>>>> change in the ordering is not persisted.
>>>>>
>>>>> I am clearly missing something ..... has anyone else had with a 
>>>>> similar issue?
>>>>>
>>>>> Any suggestions?
>>>>>
>>>>
>>>> No need to look further: AFAIK the binding currently doesn't sync 
>>>> order,
>>>> it only checks for new or removed rows. So it considers the list to
>>>> which the repeater binds to be an unordered set.
>>>>
>>>
>>> I personally use only the simple-repeater binding, because the full 
>>> content of the collection is in the rows (no other non-displayed 
>>> field). And the simple-repeater binding starts by erasing the 
>>> collection before recreating it from scratch, and in order.
>>
>>
>>
>> I had this :
>>
>> <wb:repeater id="resources"
>>     parent-path="."
>>     row-path="resources"
>>     unique-row-id="id"
>>     unique-path="id">
>>
>>     <wb:on-bind>
>>       <wb:value id="id" path="id"/>
>>       <wb:value id="text" path="text"/>
>>       <wb:value id="reference" path="reference"/>
>>     </wb:on-bind>
>>   </wb:repeater>
>>
>> But as Bruno said, it won't work with re-arranging because the 
>> Resources List is treated as a Set.
>>
>> So I tried this:
>>
>> <wb:simple-repeater
>>    id="resources"
>>    parent-path="."
>>    row-path="resources"
>> />
>>
>> but I get no data is in the form, even though I have the correct 
>> number of repeats.
>>
>
> hm, looks like this is missing the explicit binding sub-xpaths for the 
> sub-widgets?
>
>> so I tried this:
>>
>> <wb:simple-repeater
>>    id="resources"
>>    parent-path="."
>>    row-path="resources"
>>  >
>>    <wb:on-bind>
>>       <wb:value id="id" path="id"/>
>>       <wb:value id="text" path="text"/>
>>       <wb:value id="reference" path="reference"/>
>>    </wb:on-bind>
>> </wb:simple-repeater>
>>
>> but Cocoon complains thus :
>>
>> org.apache.cocoon.woody.binding.BindingException: Cannot handle 
>> binding element with name "on-bind".
>>
>> Any suggestions?
>>
>
> I think the simple-repeater is not supporting the nested on-bind 
> (yet), try removing the on-bind wrapper and have just:
>
>
> <wb:simple-repeater
>    id="resources"
>    parent-path="."
>    row-path="resources"
>  >
>     <wb:value id="id" path="id"/>
>     <wb:value id="text" path="text"/>
>     <wb:value id="reference" path="reference"/>
> </wb:simple-repeater>
>
> please let us know if this fills your repeater-rows corretly
>
> hm, as for the remark on the 'XML only' support I guess this has to do 
> with the missing object-factory for the on-insert-row event?
> (IIRC Sylvain made some generic XML oriented factory which helas can 
> not be used for Java object backends)


This analysis it right, both in the syntax and in the missing 
object-factory. I missed the important difference between Jeremy's use 
case and mine which is that I bind to an XML document.

> This sounds like simple-repeater should get some more features from 
> his more complex brother, no?


Yeah, but I'd like to keep it "simple-repeater" ;-)

> suggestion:
> introduce on-bind wrapping of the children, so we can introduce a
> on-create-row that behaves just like the on-insert-row and allows to 
> specify the classname of a jxpath-factory?


Mmmh... Do we really need a jaxpath-factory or simply a class name?

Sylvain, in an hotel in Paris with DSL in the room. Yeah!

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message