On 04/10/10 17:28, legutierr wrote:
* First, treat data processing and retrieval as separable from
rendering. Create a bright line of separation between the two
conceptual elements of the view (data and rendering), and do it early
on, at a high level, inside dispatch(). Instead of expecting the
ListView.GET to return an HTTPResponse, for example, have it return a
context or a context dictionary that could be reused with several
render_result() implementations.
This is problematic if I want to return something that isn't a context,
or like it (for example, if I'm rendering images, or fetching content
wholesale out of a database).
* Second, have the dispatch method in View call
render_result(context_dict), which will raise a NotImplemented
exception in the base class, but will return in the subclass whatever
the return data might be. This will be the locus of control for
different data implementations, and can largely be implemented without
any knowledge of the data processing details.
* Third, provide different implementations of render_result()
through the use of different mixins, each targeting a different output
style (template, json, XML, PDF, etc.). That way, the logic that
handles data processing and retrieval can be re-used regardless of
what the data output may be, and vice-versa.
* Finally, handle redirects, reloads, or 404's through exceptions,
which would be processed inside dispatch() as well. Using exceptions
for normal flow of control is generally frowned upon, but here it
would allow for a simplified API description for calls to GET(),
POST(), etc.: These methods would return a dictionary in the standard
case, and raise specialized exceptions for redirects, reloads, or file-
not-founds and other deviations from the "norm."
The current implementation is already using mixins in order to
maximize code reuse in form processing. It seems that using mixins to
modify rendering behavior would also be appropriate. And if mixins
are unacceptable for the documented API ("mixins are a relatively
unused part of Python, and multiple inheritance can cause some odd
bugs"), the same compartmentalization can be achieved, albeit in a
more repetitive way (copy and paste), by simply overriding
render_result(context_dict) in direct subclasses of ListView,
DetailView, etc. Most significantly, however, it would be much easier
to document how a user can add his or her own response data type if
such a thing were limited to nothing more than overriding
render_result(context_dict).
Of course this is just one example of an approach. There are other
approaches that would also be an improvement over what is implemented.
So, bfirsh's previous iteration had content formats built into the base
class - I ripped it out and replaced it with a simpler base class, and
he seemed to agree, so that's where we currently are.
My main concern is getting rid of the simplicity - e.g. of calling
render() on a template/context mix. In this aforementioned previous
iteration, if I wanted to supply custom context to a custom template, I
had to override both self.get_template_name() and self.get_context() -
even though it would have been a lot easier to override GET and just
call self.render(). It's a similar problem to passing everything around
as keyword arguments - reusability doesn't turn out to be much better
than starting from scratch.
(FWIW, I've written several hundred LOC with both styles and it was a
lot less work when there was less abstraction)
I just don't want us to build in all these abstraction layers and have
the ability to customise everything perfectly but in a verbose fashion.
That said, if render_result() in your example just calls a normal
render() method itself, it's easy to not use it if you don't have to, so
a reasonable approach to get both of these angles in is possible.
Also, what use cases do people have for returning arbitary pages as JSON
or XML?
I'm not saying there aren't any - far from it - but I much prefer
evidence to speculation, so some concrete examples would be great
Finally, we have to be wary of making this automatic on all views, or
something similar - it could potentially be a
security/warm-fuzzy-feeling risk, as some people put things into the
context that aren't necessarily for display to the user (though you'd
have to be pretty stupid to put anything actually sensitive in there).
(There's also the issue of whether you apply context processors to the
JSON replies, and so forth, but that's going even further down the
rabbit hole)
Andrew
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
