> I like having access to the models attributes, such as
> get_absolute_url, we use things like this quite a bit in our templates
You could relatively painlessly 'flatten' the attributes of the model
instances in place before rendering template, i.e.
spam.get_absolute_url = spam.get_absolute_u
> Why don't you just generate lists and dictionaries in the view and send
> those to your templates instead of data objects?
I like having access to the models attributes, such as
get_absolute_url, we use things like this quite a bit in our templates
> 1. It'd be pretty easy to write a template t
Why don't you just generate lists and dictionaries in the view and send
those to your templates instead of data objects?
--
Gustavo Picon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To po
On 1/9/07, David Cramer <[EMAIL PROTECTED]> wrote:
> Using full page caching, or view caching, is not an option for us on
> most pages, as things vary such as moderation options.
There are still plenty of ways you can make use of the cache. From
what you've said, I think two in particular are wor
Using full page caching, or view caching, is not an option for us on
most pages, as things vary such as moderation options.
On Jan 10, 5:26 am, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On 1/9/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > I don't think you understand. We do not want the te
On 1/9/07, David Cramer <[EMAIL PROTECTED]> wrote:
> I don't think you understand. We do not want the template to be able to
> execute any queries that have not already been done by the time it's
> hit the render phase. If it hasnt been executed, we don't want it
> accessible. The reason for this
I don't think you understand. We do not want the template to be able to
execute any queries that have not already been done by the time it's
hit the render phase. If it hasnt been executed, we don't want it
accessible. The reason for this is to stop queries going outside of our
cache and/or view.
On 1/9/07, David Cramer <[EMAIL PROTECTED]> wrote:
> I'd like to come up with an optional, or simply, a solution for our
> framework, where designers do not get access to do the SQL through the
> template on related attributes.
Also, bear in mind that this option locks you in to the unpleasant
si
On 1/9/07, David Cramer <[EMAIL PROTECTED]> wrote:
> I'll happily modify django for what I want, I just need some help on
> where to start... as I dug around for an hour or two the other day and
> couldn't see where exactly the related objects execute the lazy sql. If
> nothing else, I guess I cou
select_related is horrible slow on 90% of large database queries, and I
haven't managed to implement the functionality I want in it yet.
I'd like to come up with an optional, or simply, a solution for our
framework, where designers do not get access to do the SQL through the
template on related a
reinmar wrote:
> Hi David,
> This sounds truly disturbing. Can you give an example of how your
> templates execute SQL queries? That would help in giving specific
> advice.
David,
Ignore that, I missed the discussion at the duplicate post
http://groups.google.com/group/django-users/browse_threa
Hi David,
This sounds truly disturbing. Can you give an example of how your
templates execute SQL queries? That would help in giving specific
advice.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" g
On 1/9/07, David Cramer <[EMAIL PROTECTED]> wrote:
> I want to setup some kind of blocking mechanism so that while rendering
> a template the models will not do any SQL queries that have not already
> been executed, or at least block the related field queries.
Unfortunately I think this would be
On 1/9/07, David Cramer <[EMAIL PROTECTED]> wrote:
>
> I'm talking completely about the related objects accessors, and not
> sending models to the templates is not a good solution for us :)
>
> I want to setup some kind of blocking mechanism so that while rendering
> a template the models will not
I'm talking completely about the related objects accessors, and not
sending models to the templates is not a good solution for us :)
I want to setup some kind of blocking mechanism so that while rendering
a template the models will not do any SQL queries that have not already
been executed, or a
On 1/8/07 4:53 PM, Adrian Holovaty wrote:
Templates don't have the "ability to execute SQL" -- it just happens
that the Django database API executes SQL via attribute access in some
cases (e.g., in the case of related objects via a foreign key) and I
assume you're using that attribute access in
On 1/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
It is hell optimizing content when you don't know where some of the
queries are executing from, and if I was missing information, it'd be
much easier to see that, than it would be to see that I've got X query
executing in X template.
The
On 1/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I'm petition this as a core change, if nothing else, I'm seeking advice
on how to go about it.
I do *not* like templates having the ability to execute SQL. If I don't
have the data once its past my view (as this is MVC, control doesnt
need
I'm petitioning this as a core change, if nothing else, I'm seeking
advice
on how to go about it.
I do *not* like templates having the ability to execute SQL. If I don't
have the data once its past my view (as this is MVC, control doesnt
need to get the data, it just needs to control it), I don'
I'm petition this as a core change, if nothing else, I'm seeking advice
on how to go about it.
I do *not* like templates having the ability to execute SQL. If I don't
have the data once its past my view (as this is MVC, control doesnt
need to get the data, it just needs to control it), I don't w
20 matches
Mail list logo
