cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: wb:delete-bean?
Date Wed, 05 May 2004 07:06:52 GMT


Mark Lundquist wrote:
> 
> On May 4, 2004, at 10:54 AM, Joel McConaughy wrote:
> 
>> I'm using hibernate/cforms to build simple CRUD pages.
> 
> 
> Have you seen the alternative acronymn?: Create/Read/Amend/Purge :-)
> 
>>  These take the
>> results from a query and create an ArrayList of beans, display a page
>> worth of rows in a repeater, allow in place editting, and persist the
>> results back to the database.
>>
>> Hibernate handles row updates automatically.  Insertions are handled in
>> the flow by explicitly calling a hibernate save operation on any row
>> with a null ID.
>>
>> Deletions are the problem.  Hibernate requires that I explicitly call a
>> delete method for each deleted row.  Cforms doesn't keep track of
>> deleted rows within a repeater so I believe that I need to do this as
>> each delete event is fired.  However, I don't know how to access the row
>> inside the <wb:on-delete> tag or how to call some external Java from
>> there.
>>
>> May be there's an easier way to accomplish this?
> 
> 
> I know you can do it with the v2 forms/flow API... see the flowscript in 
> the v2 samples directory.
> 
> There might be a way to do it with the  <wb:on-delete> way, but I'll let 
> somebody else answer that 'cause I don't know! :-)
> 

I don't think there is that much to know though, since it doesn't do it 
ATM, (and thx for making me realize the goal here)

binding's save() on the repeater tries to 'identify' which rows have 
been lost and just executes the nested on-delete binding on those (this 
might sound like an event, but is not executed on the moment the row 
actually gets deleted, as such binding is not an interceptive part of 
the form-model but just a pre/post processing for loading/saving values)


the current row-delete/update/insert recognition has been reported in 
the past to be somewhat limited for certain use cases, and many people 
have been adding their own implmentations (in fact with the 
Custom-binding you could easily add one like that as well)

in any case: some thought has been already given on unifying all those 
repeater-implementations to make it more complete out of the box... it's 
on my personal todo (somewhere) which means I'll welcome any additional 
ideas or better: ready patches :-)

to read up on some of the new binding ideas:
- http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108059910416310&w=2
- http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108209653422163&w=2
- http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108194795223412&w=2

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message