Re: Vote on {% include %} behaviour.

I would personally prefer to be able to specify whether the "include" should be rendered at the compile time or at the rendering time. For some applications it is really useful to have recursive inclusion of templates, which is impossible with compile-time inclusion. For example, a few days ago I

Re: Form Rendering API Proposal

> > {% formconfig widget widgets.Textarea for "comment" %} > {% formconfig row using "forms/rows/ul.html" %} > > The first statement instructs the form to use a textarea widget for any > formfield named "comment." The second instructs the form to use ul's as the > default formrow template anytime

Re: How to send a form value from a template to a view , both in different apps ?

On Fri, Jun 24, 2011 at 10:59 AM, Satyajit Sarangi wrote: > Hello > I had posted there . But never got a reply  .Thus I though , django > developers group would help me out . There are many possible reasons that you may not have received a reply. Perhaps nobody

Re: How to send a form value from a template to a view , both in different apps ?

Hello I had posted there . But never got a reply .Thus I though , django developers group would help me out . >Hi Satyajit, >You've mailed this to Django-developers, which is the list for >discussing the development of Django itself. It isn't a forum for >asking general "how do I" questions.

Re: How to send a form value from a template to a view , both in different apps ?

On Fri, Jun 24, 2011 at 10:27 AM, Satyajit Sarangi wrote: > This is my views.py ... > But its not linking . How exactly should I do it , such that I can > access the view from this template and also send the form value to > it . Hi Satyajit, You've mailed this to

How to send a form value from a template to a view , both in different apps ?

This is my views.py def map_display(request): if request.method == 'POST': form = DispForm(request.POST) if form.is_valid(): this_user = request.user user1= this_user.pk LName =

Re: Contextual autoescaping for Django templates

Ok. I'll hold off for now and maybe reopen this thread after there's a better sense of how custom processing passes plug in. On Jun 23, 4:51 pm, Alex Gaynor wrote: > No, there is at this.point no concrete proposal. > > Alex > On Jun 23, 2011 4:04 PM, "Mike Samuel"

Re: Form Rendering API Proposal

On 06/23/2011 04:43 PM, Jacob Kaplan-Moss wrote: > 1. Performance: it looks, to me, like rending a basic form is going to > cause dozens of template includes and dozens of sub-renders (the form > loads a form template which loads row templates which load widget > templates). That's dozens of disk

Re: Contextual autoescaping for Django templates

No, there is at this.point no concrete proposal. Alex On Jun 23, 2011 4:04 PM, "Mike Samuel" wrote: > > > On Jun 23, 11:36 am, Alex Gaynor wrote: >> FWIW it's likely that Armin and I will be proposing a new, higher level, >> template tag API in the

Re: Contextual autoescaping for Django templates

On Jun 23, 11:36 am, Alex Gaynor wrote: > FWIW it's likely that Armin and I will be proposing a new, higher level, > template tag API in the coming weeks/months, as the current API is > fundamentally incompatible with good template compilation. > > Alex Good to know. Is

Re: Form Rendering API Proposal

Le 23/06/2011 14:33, Jonas H. a écrit : On 06/23/2011 02:11 PM, Harro wrote: - Will the as_* methods on forms be deprecated? They seem to be a nice shorter version then the new way to do it. I'd rather provide a shorter version of {% form %} for built-in layouts: {% form foobar 'table' %} as

Re: Should test failures/errors in the Django test suite when executed under MySQL be considered blockers?

And if is a real problem in the MySQL support, I'm willing to look into it. I use it in production. You might have to poke me directly but I am trying to pay attention lately. On Thu, Jun 23, 2011 at 5:53 PM, Jacob Kaplan-Moss wrote: > Hi Jim -- > > Historically, most Django

Re: Should test failures/errors in the Django test suite when executed under MySQL be considered blockers?

Hi Jim -- Historically, most Django core developers have been PostgreSQL users (and advocates to some degree). This has meant that, yes, MySQL support has lagged behind. It's not that MySQL support isn't considered important, but it is a matter of priorities. I, at least, am going to prioritize

Re: Form Rendering API Proposal

Hi Idan et al. -- Thanks for putting this all together! In general, I like this a lot, and I'm always going to defer to the eyes of someone like Idan who spends more time wrangling templates than I do. So I like the general gist, and I most don't mind the {% formconfig %} business. However, I

Should test failures/errors in the Django test suite when executed under MySQL be considered blockers?

I've been trying to do a little work recently on some tickets that related to MySQL-specific issues that come up using Django (#2495 and #3615 specifically). As part of trying to get my head around resolving these, I executed the test suite in the current Django trunk using a MySQL InnoDB

Re: Form Rendering API Proposal

I've been working on something almost identical to this. But your formconfig is what really gives it that last piece that I didn't have, very nice! I doubt that it's helpful, but I just put my code up at: https://github.com/bunchesofdonald/django_amaro it's still very early stages, and needs

Re: Contextual autoescaping for Django templates

On Thu, Jun 23, 2011 at 11:35 AM, Mike Samuel wrote: > > > On Jun 21, 3:55 pm, Luke Plant wrote: > > On 21/06/11 20:07, Mike Samuel wrote: > > > I'd like to add contextual autoescaping to django templates. > > > > > Briefly, it would automatically

Re: Contextual autoescaping for Django templates

On Jun 21, 3:55 pm, Luke Plant wrote: > On 21/06/11 20:07, Mike Samuel wrote: > > I'd like to add contextual autoescaping to django templates. > > > Briefly, it would automatically pick filters for each {{variable}} by > > looking at the context in which it appears.  So

Re: Form Rendering API Proposal

This looks excellent so far. Do {% formfield %} and {% formrow %} accept context like {% form %} does? Is there a way with {% formfield %} or {% formrow %} to set custom attributes like placeholder, autocorrect, etc.? I find this common requirement when optimizing forms for mobile devices.

Re: Form Rendering API Proposal

On Thu, Jun 23, 2011 at 10:11 AM, Idan Gazit wrote: > > > On Thursday, June 23, 2011 4:06:05 PM UTC+3, dmoisset wrote: >> >> What is the "significant wart" ? > > The formconfig tag is a little bit "magical"; there's no other example in > the template langauge of something

Re: Form Rendering API Proposal

On Thursday, June 23, 2011 4:06:05 PM UTC+3, dmoisset wrote: > > What is the "significant wart" ? > The formconfig tag is a little bit "magical"; there's no other example in the template langauge of something explicitly affecting state in the same fashion. Even things like the "with" tag are

Re: Making sitemaps more extensible (or providing for existing extensions)

Ticket #15829 (https://code.djangoproject.com/ticket/15829) includes a patch that allows exposing the item object the template, which is all that is needed to support any of the specific sitemap extensions. Regards, Michael Manfre On Jun 22, 8:05 pm, Jeremy Dunck wrote: >

Re: Form Rendering API Proposal

On Thu, Jun 23, 2011 at 8:25 AM, Idan Gazit wrote: > At DjangoCon Europe 2011, Gregor Müllegger gave a great lightning talk about > his work on a revised form rendering API: >

Re: Form Rendering API Proposal

On 06/23/2011 02:11 PM, Harro wrote: - Will the as_* methods on forms be deprecated? They seem to be a nice shorter version then the new way to do it. I'd rather provide a shorter version of {% form %} for built-in layouts: {% form foobar 'table' %} as shorthand for {% form foobar

Re: Form Rendering API Proposal

Hi Harro, 2011/6/23 Harro : > Two things: > - Will the as_* methods on forms be deprecated? They seem to be a nice > shorter version then the new way to do it. The plan is to deprecate them. First reason is that the new approach is more explicit of what happens. The second

Re: Form Rendering API Proposal

Two things: - Will the as_* methods on forms be deprecated? They seem to be a nice shorter version then the new way to do it. - I assume the formconfig calls are for the current context, but can I set them in the base.html and then automatically have them used in all templates extending the

Form Rendering API Proposal

At DjangoCon Europe 2011, Gregor Müllegger gave a great lightning talk about his work on a revised form rendering API: http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger I sat down with Gregor, Jannis, Russell, Alex, Ericflo, Andrew

Re: Django project dependencies

This question/discussion is off-topic for django-developers, which focuses on the development of Django itself. Please post questions like this on django-users. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group,

Django project dependencies

I wrote an article about handling django apps. Also I received some critics on it. Man topic is that I'm suggesting copy any pugin(django redistributable app) directly into project folder instead of using virtualenv. Am I right? You may read this article in