Proposal: {% include_partial %} template tag
Hi all,
I'd like to propose adding a tag that includes a template with clean
context, but can accept parameters that will be added to that
context.
The use-cases are plenty, but I've been using it mostly with forms, as
it helps to keep the template code DRY and very customizable. We could
use the {% with %} and {% include %} tags to do the same of course,
but I think something like {% include_partial "forms/textfield.html"
field=person_form.first_name label="First Name:" %} is much cleaner.
This is similar to a rails tag called "render_partial" and there's a
draft at http://gist.github.com/427116 based on
http://freeasinbeard.org/post/107743420/render-partial-in-django
Thanks
--
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.
Re: Proposal: {% include_partial %} template tag
I'd prefer extending the {% include %} tag actually, but didn't of
that in the first place.
The clean context implementation was to make sure we don't pass
variables we don't want to. One of the use-cases is including form
field "templates", so I have code like:
{% if label %}
{{ label }}
{% else %}
{{ field.label_tag }}
{% endif %}
if there was a "label" variable in the context but not in the
parameters, the code above would output the wrong values. There is one
problem with not inheriting the context: {% csrf_token %} will fail.
On Jun 7, 5:35 pm, Łukasz Rekucki wrote:
> On 7 June 2010 18:13, Jacob Kaplan-Moss wrote:> On Mon,
> Jun 7, 2010 at 5:03 AM, Marco Louro wrote:
>
> >> I'd like to propose adding a tag that includes a template with clean
> >> context, but can accept parameters that will be added to that
> >> context.
>
> > Is there a reason to do this as a separate tag? Why not just::
>
> > {% include "some/template.html" with foo=bar baz=spam %}
>
> Personally, I would expect this to extend the current context with
> "foo" and "bar", render the include and restore foo, bar to old values
> (if any). Using a clean context instead is a bit non-obvious to me.
>
> --
> Łukasz Rekucki
--
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.
Re: Proposal: {% include_partial %} template tag
Gabriel,
I only made that decision because I didn't see the need to have whole
context, and the only time I have needed it was because of the {%
csrf_token %}. This is just my use-case, but I understand that other
people might want to use it differently. I don't think it makes much
of a difference, a clean context may avoid some collisions from time
to time, but it may have bigger drawbacks for other people.
Hi Jeliuc,
No, I don't.
On Jun 7, 7:59 pm, Gabriel Hurley wrote:
> Extending the include tag seems like a fantastic idea! I end up
> writing the {% with %}{% include %} combo all the time for my reusable
> template snippets.
>
> However, I feel like selectively clearing the context inside a
> template tag is asking for trouble and/or confusion. It also sounds
> like it goes against Django's "templates require no knowledge of
> programming" principle. While I can see how you might run into context
> name collisions in a *very* large or complicated project, the right
> solution there seems like it ought to be to clean up your context and/
> or templates outside of the template itself... Even in projects with
> dozens of installed apps (both my own and third-party ones mixed
> together) I've never had that problem where two minutes of tweaking
> couldn't fix it for good.
>
> I'm certainly not saying you don't have a use case for it, or that it
> wouldn't be extremely helpful to you. Just that having a tag that
> clears the context sounds fishy to me...
>
> All the best,
>
> - Gabriel
>
> On Jun 7, 10:52 am, Marco Louro wrote:
>
>
>
> > I'd prefer extending the {% include %} tag actually, but didn't of
> > that in the first place.
>
> > The clean context implementation was to make sure we don't pass
> > variables we don't want to. One of the use-cases is including form
> > field "templates", so I have code like:
>
> >
> >
> >
> > {% if label %}
> > {{ label }}
> > {% else %}
> > {{ field.label_tag }}
> > {% endif %}
> >
>
> > if there was a "label" variable in the context but not in the
> > parameters, the code above would output the wrong values. There is one
> > problem with not inheriting the context: {% csrf_token %} will fail.
>
> > On Jun 7, 5:35 pm, £ukasz Rekucki wrote:
>
> > > On 7 June 2010 18:13, Jacob Kaplan-Moss wrote:> On
> > > Mon, Jun 7, 2010 at 5:03 AM, Marco Louro wrote:
>
> > > >> I'd like to propose adding a tag that includes a template with clean
> > > >> context, but can accept parameters that will be added to that
> > > >> context.
>
> > > > Is there a reason to do this as a separate tag? Why not just::
>
> > > > {% include "some/template.html" with foo=bar baz=spam %}
>
> > > Personally, I would expect this to extend the current context with
> > > "foo" and "bar", render the include and restore foo, bar to old values
> > > (if any). Using a clean context instead is a bit non-obvious to me.
>
> > > --
> > > £ukasz Rekucki
--
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.
Django urls in JavaScript
I don't really know how to approach this issue the best way, so I'm
just going to be direct, I'd love to see Django provide support for
django.core.urlresolvers.reverse (at least) on the client (in
JavaScript).
I'm pretty sure all who have needed to make AJAX queries have dealt
with the issue of "where do we store our urls". The urls are, I'd
guess, 99% of the time, defined in Django, and I think that it usually
comes down to two approaches:
1) hard-code them: $.post("/hello/" + what + "/")
2) Store them in a variable or object: var hello_url = "{% url
hello_url what.id %}" - But if you need to "generate" the url based on
an id, this doesn't work.
There are more solutions of course, but these are the quick and easy
and I assume it's what most people use, and yes, it's just not elegant
and DRY.
What I'd like to propose to fix it:
1) Create a django namespace in JavaScript
2) Create a django.urls module, and implement reverse (and maybe
resolve)
3) Create a way to load urls from Django into JavaScript's django.urls
module (as django.urls.url_list or whatever) - of course, we don't
want all urls to be listed.
So my question is, is there any interest in getting something like
this into Django itself?
I think that with staticfiles bundling JavaScript for use outside of
the admin is possible and easy, but I also understand it's a sensible
matter even thou this wouldn't require any external libraries. I do
have an implementation of a urls module (https://github.com/mlouro/
olivejs/blob/master/olive/urls/urls.js) and tests (https://github.com/
mlouro/olivejs/blob/master/tests/urls.js), but it has a lot more stuff
attached that would be out of scope, as I think the urls themeselves
are a really important bit that Django should make available on the
client-side.
Thanks,
Marco
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Django urls in JavaScript
That's also already done, check
https://github.com/django-extensions/django-extensions/blob/master/django_extensions/management/commands/show_urls.py,
it can be easily converted to JSON (I have a branch that does it, but
it's not up-to-date).
I also have the urls module in JavaScript already, but as part of a
larger library (https://github.com/mlouro/olivejs/blob/master/olive/
urls/urls.js), both have been used in projects.
An example:
/* below is the output from "manage.py show_urls" in JSON format */
olive.urls.load({
'dashboard': '/dashboard/',
'time_edit': '/projects//time/save//',
'task_edit': '/projects//task/save//'
});
olive.urls.get('task_edit', {
'project_id': 2,
'task_id': 1
})
On Mar 24, 3:31 pm, Matt Robenolt wrote:
> I think the biggest problem with translating the reverse() lookup is the
> lack of kwargs and named capture groups in Javascript regex. So a pattern
> such as: /page/(?P\d+)/ would not translate whatsoever. Then on the
> Javascript side, we wouldn't be able to use: reverse('goto_page', [],
> {page_id: 5}); It would have nowhere to map up the page_id variable to. We
> could probably get away with some sort of pseudo regex rules in Javascript.
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Generic relations and Multi-table inheritance bug?
Hi, The easiest way to explain this is with code I guess: http://dpaste.com/104502/ These are the models for a contact management application. Basicly I have a "Contact Model", which is used to hold details for both the "Person" and "Company" Models. On the "Contact Model" I have some generic relations, for example, Email.. I'm using generic_inlineformset_factory to handle the Forms for the generic relations, and it works well. Any data I save on the forms is saved linked to the corresponding Person Contenttype. The problem: If I do this: entity = Person.objects.get(id=contact_id) entity.emails.create(address="t...@mail.com2") print entity.emails.all() It is not saved as a Person Contenttype as one would expect, but as a ContactContenttype, but it does save with the correct Person Id. If I have a Company and a Person with the same Id, the object_id in Email will be the same, and the content_type_id will also be the same, since it currently saves as a Contact, and not as a Person or Company. Hope I was clear.. --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multi-DB Week 0 Update
Hey Alex, Not sure if this is the right place, but I guess you're the right person to ask.. Will Multi-BD be flexible enough that it will allow to choose a DB at runtime, depending on something like the user or the domain and not tied to models at all? From what I've read that's not possible right now (don't need to change backends, just database name, password and server), and it's also not easy. Thanks, Marco On May 23, 5:05 am, Alex Gaynor wrote: > Hey all, > > GSOC is officially scheduled to start tomorrow (my time), however I've take > the liberty of getting quite a jump on my work (as I described last week). > During this week I got the save using parameter and using queryset method, > these are fairly untested however. The reason for this was after updating > the management commands and testing harness for multiple database support > any fixtures being loaded would be loaded N time (where N is the number of > dbs in your settings.DATABASES setting), so I needed to make sure each > fixture got loaded into each DB, this meant adding the using parameter to > save, which also uses querysets... and it was turtles all the way down :) > > So while that's basically working, the test suite as a whole is still not > passing (http://paste.pocoo.org/show/118532/is the results for me). The > reason for this (as best I can tell) is that Postgresql runs DDL operations > inside a transaction, and since transaction support isn't actually working > across DB at this point the CREATE TABLE statements never actually get > committed. Which brings us to the problem: updating the transaction stuff > in itself isn't a huge task, and making django use transaction stuff where > necessary isn't tremendously onerous. However, one of > > -- > "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 --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
