Vicvicvic,
I think your on to something here. However, we need to remember that
one of the great things about Django views is that they are just
python functions. You can do pretty much anything you want. So, if
someone wants to build up a complete html page in python code without
any templates, they can. It will be a maintenance headache, so it's
not recommended, but its not wrong.
If you want to build up a library of decorators that simplify your
views (and, no doubt, speed up your work), then you are free to do so.
And if you want to share that library with others, that's even better.
In fact, if you search through djangosnippets.com, I believe you'll
find a few snippets that do some of the same things your talking
about.
However, I don't expect that the Django core will take on your
approach as the "preffered" way to do things. The flexibility of the
views to allow various coding styles is one of Django's greatest
strengths. You can do what works for you and I can do what works for
me.
So keep it up. Share your work and make Django a better place for
others who like that style of coding. Just don't expect the entire
community to embrace it as the "only way".
On Tue, Jul 15, 2008 at 6:36 AM, vicvicvic <[EMAIL PROTECTED]> wrote:
>
> In the Django FAQ, we can read this about views:
>
>>In our interpretation of MVC, the "view" describes the data that gets
>>presented to the user. It's not necessarily how the data looks, but which
>>data is presented. The view describes which data you see, not how you see it.
>>It's a subtle distinction.
>
> In my mind, "which data you see" would be equal to a context a view
> returns, not the HttpResponse or the template. Why? Because rendering
> a template is saying "I have this data and I want it presented the way
> this template will present it". If the view is responsible for saying
> that, it is at least partly responsible for telling us how we see the
> data.
>
> Rather, if a view ONLY returned a dataset, something else would be
> responsible for displaying this. In more practical terms, if a view
> returns a dataset, instead of a full response, another mechanism would
> be wholly in charge of formatting the data. This mechanism may then
> choose which template to render, or to not render a template at all,
> and just pass the dataset along.
>
> Why is this useful? For the sake of minimizing views, but provide a
> rich amount of formats. The format-choice mechanism can investigate
> the request (HTTP Requests come with an Accept-header) and see what
> format has been requested. Looking at Accept would be the proper way
> of doing it, but it might be easier to make URLs like /forums/threads.
> (?P<format>html|json|xml)
>
> HTML? Render that template. JSON? Render that template (or just
> serialize the dataset). XML? RSS? You get the idea: The formatter
> takes the data and tries to present it, making it a bridge between a
> view and a template.
>
> Furthermore, the same mechanism could be asked to process an
> "internal" request, that is another Python function requesting the
> data. Right now, I have a couple of views which return some data. But
> I'm also building another view, and I want the data from one of the
> first views in this one. I can either duplicate the fetching from the
> first one, or I can send an "internal" request and just get the
> dataset. I pick WHICH data I want and add some to it.
>
> My current solution:
>
> I've written a very crude decorator to demonstrate/use this in my own
> projects, but I'm note sure if posting code looks any good on Google
> Groups. Summarized:
> My decorated views return their dataset as a dictionary.
>
> The decorator takes two parameters: template and formats. template is
> the usual path to a template, but without an extension. formats is a
> tuple of formats (('html','json')) which the view is considered able
> to render.
>
> Upon calling the view, the decorator intercepts its arguments. It
> looks for a format-parameter and an internal-parameter. If internal is
> True, it lets the view run and just returns the resulting dictionary
> to whatever called it. If not, it checks that format is in formats and
> then tries to render_to_response("%s.%s" % (template, format,
> returned_dict, RequestContext(request))
>
> As I said above, the mechanism (in my case, a decorator) should
> probably try to investigate what the request looks like, rather than
> checking for stuff in the URL/other parameters but as I said, it's
> crude. It should also return the proper Content-type.
>
> --
>
> Do you think I have a point? Me not being a Django developer (and not
> a very seasoned Python user at all), I realize I might have
> misunderstood your... philosophy :)
> >
>
--
----
Waylan Limberg
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
