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

Attachment: smime.p7s
Description: S/MIME cryptographic signature



Reply via email to