On 1 October 2010 07:26, Russell Keith-Magee <[email protected]> wrote: > I already have one specific piece of API feedback: the current > implementation requires that all view logic is contained in GET(), > POST() etc style views. This is fine, except for the fact that there > are occasions where GET and POST share a lot of common logic.
This! is! Python! Any shared logic can be in another method, or function for that matter, and need not be canonicalized in an API. All that would be needed is an example in the docs: class TheView(views.ClassView): ....def _common(self, bla): ........# set up models, forms, other preprocessing here ........# return models/forms or set them on class ........# could be run from __init__ or __new__ or whatever we wind up with ....def GET(self, bla): ........self._common(bla) ....def POST(self, bla): ........self._common(bla) (Indent-dots to make surer that gmail doesn't meddle with the text.) Surely class-based views shouldn't disallow methods not named nor given meaning in an API? Since you needed to explicitly wish for a specific method, that's how it can be interpreted. HM -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
