Take a look at http://http://products.bluedynamics.org/Products/Znolk, a 
wizard method which generates a wide variety of different Zope methods 
for maintaining databases.

I don't understand your concurrent update issue.  Such problems should be 
handled by the backend database, careful table design, and by using 
transactions when doing the update.

On Sat, 18 Jun 2005, Ralph wrote:

> I'm new to Zope and made a small database application with zope (mostly DTML) 
> to learn the idea behind Zope, but I'm not satisfied with the structure of my 
> application.
> I have for each table a Form (DTML-method) with 3 buttons 
> (new,update,delete). 
> Each button triggers a DTML-script "actionTable"
> actionTable calls either a DTML-method to display a form (update, insert) or 
> calling the zsql-method to delete a data record. The disadvantage with this 
> structure is, that it is difficult to maintain  programs like this. I wish to 
> have optimistic locking but to send variables to the next DTML-method is a 
> hell. 
> Example: I you have a database table with the rows id,name and desc I have to 
> send all record values through all methods after the user is triggering 
> update to secure that there is no concurrent update. But with my design 
> approach it's not possible.
> Is there someone who has a better design approach or an idea?

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to