Re: [Zope] An observation about manage_* methods
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 ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] An observation about manage_* methods
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 ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] An observation about manage_* methods
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 [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
