cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: persisting re-arranged repeater-rows
Date Wed, 26 Nov 2003 19:30:31 GMT

On 26 Nov 2003, at 10:52, 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

I'll get back to you about this ....

> 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 sounds like simple-repeater should get some more features from  
> his more complex brother, no?

Or make the (complex)Repeater List savvy ......

> 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?
>
> wdyt?
>
>> thanks
>> regards Jeremy
>
>
> Jeremy,
>
> Just for my interest: if I get it correctly, then the order of some  
> records seems to be of importance for you app?

Yes, authors will want to re-arrange the order of the Resources,  
arbitrarily.

> Mapping this to a database would mean that those records have a  
> sequence-number-field, correct?

Correct:

arches=# select * from resources;
  id    |      reference                   |              text            
                                | albumid    | posn
----+---------------------+---------------------------------+--------- 
+------
  14   | 123/testing/testing        | very interesting ... but stupid     
              |      12       |    0
  13   | 321/testing/testing        | blah                                
                         |      12       |    1
(2 rows)


> I'm not completely into hibernate, but from your story I get the  
> impression that you can tell the hibernate-mapping that that  
> sequence-number needs to be used as the index-number into the list?  
> (groovy stuff!)

Like this (the relationship is defined in the parent) :

<class name="uk.co.my.bean.Album" table="albums">
	<!-- Hibernate's record ID -->
	<id name="id" column="id" type="long">
		<generator class="native"/>
	</id>
	<!-- simple properties -->
	<property name="title" type="string" length="128" not-null="true"/>
	<property name="text" type="string" length="1024" not-null="true"/>
	<property name="publishable" type="boolean" not-null="true"/>
	<property name="modified" type="timestamp"/>
	<!-- the 'many' end of a (true) bi-directional one-to-many  
relationship to User,
	        because we do not need to make the Albums re-arrangeable  -->
	<many-to-one name="user" class="uk.co.my.bean.User" column="userid"  
not-null="true"/>
	<!-- Album has a List of Resources as children -->
	<list name="resources" table="resources" cascade="all" lazy="true">
		<!-- use the 'albumid' column of Resource to define the parent -->
		<key column="albumid"/>
		<!-- use the 'posn' column of Resource to maintain the order of the  
children -->
		<index column="posn"/>
		<one-to-many class="uk.co.my.bean.Resource"/>
	</list>
</class>

'albumid' and 'posn' are not defined as properties in the Resource, so  
they are not available to the Resource Object. They are used internally  
by Hibernate in this case.

Hibernate does not currently allow you to mix Indexed and  
Bi-directional relationships, so the relationship :

Album (1) <--> (0 .. n) Resource

Has to be one-way for the indexing of Resources to work.

The Resource looks like this:

<class name="uk.co.my.bean.Resource" table="resources">
	<id name="id" column="id" type="long">
		<generator class="native"/>
	</id>
	<property name="text" type="string" length="1024" not-null="true"/>
	<property name="reference" type="string" length="512" not-null="true"/>
</class>

I generate my database tables from the mapping files, using a tool that  
comes with HIbernate, called from an Ant Target, it is all very  
convenient ;)


regards Jeremy

Mime
View raw message