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.


Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to