On Mon, Oct 4, 2010 at 1:04 PM, Andrew Godwin <and...@aeracode.org> wrote:
> 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.
>
>
Given that the primary complain against the __new__ solution is that
it's unintuitive to Python programmers that instantiating their class
results in some other class, why not simply go with a more explicit
classmethod. Simply used as:
url("^articles/$", ArticlesView.dispatch).
It seems to address all concerns: it's explicit, safe to assign
attributes, Pythonic, and fails loudly if used improperly (using
AritlcesView would result in an Exception being throw since it doesn't
return an HttpResponse, and using, and ArticlesView() an error about
not being callable).
Last idea, I swear,
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
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.
