This has a question to it if I am not overlooking something. I often want to design dtml_methods that allow the end user to manage content under his control. An example of a typical manage method that you often see is like:
From TinyTable.py:
def manage_editData(self, data, REQUEST=None): """Change item data""" self._rows = map(self._FixRow, ImportExport.ImportData(data)) self._n_rows = len(self._rows) self._GenerateIndex() return self.manage_editedDialog(REQUEST) Now there is an assumption in this code that the editing context that this is being called from is some manage_ method, hence returns like "return self.manage_editedDialog(REQUEST)". This is annoying if you are writing a user-managed content method that does not wants the user to see the manage interface because eventually it goes to one with such returns. Instead, I would like to have control on where he/she returns (often to the method I wrote or to index_html). I could do a <dtml-call "RESPONSE.redirect..., but the return self.manage_editedDialog(REQUEST) gets in the way. Am I overlooking something or is this a weakness in this design pattern for management? I could wind up making my own version of manage_editData that does not do the return self.manage_editedDialog(REQUEST). (I know some code at least conditionalizes this to the presence of REQUEST.) Thoughts? Ideas? Regards, Albert Boulanger aboulanger@ldeo.columbia.edu
albert boulanger wrote: <snip "go somewhere else after usign a manage_ method"> All good points, there's a thread on this on zope-dev right now. I think this area is a good candidate for a new interface... Maybe it should be discussed on the zope-dev thread and then have somethign done on dev.zope.org? cheers, Chris
participants (2)
-
albert boulanger -
Chris Withers