albert boulanger writes:
.... 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.) Many methods use:
if REQUEST is not None: do something: e.g. redirect or return In this case, you simply do not pass REQUEST. If you find a method that is not conditional on "REQUEST", use "dtml-call". This will discard the return value and should work, unless the code raises an exception. Maybe "try/except" can be used to handle the exception. Dieter