1.Disk hits can be avoided using the django.template.loaders.cached.Loader.
We have a form rendering system that uses a lot of templates and it's being
used in some pretty big websites, so far I haven't notices performance
issues because of form rendering and we haven't use the cached loader as o
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
>
> {% 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 a
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 understood your question. Consider
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. T
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 Django-developers, which is the
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 = form.cleaned
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" wrote:
>
> > Good to know. Is
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 h
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 coming weeks/months, as the current API is
>> f
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 there a draft of that t
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
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 core developers have
Thanks Jacob. At a minimum, I will at least try to wade through and open a
few tickets if they aren't already open and upgrade bugs that are causing
test suite errors or failures to release blocker. I did want to make sure I
was not overstepping any bounds in assuming those were blockers.
Cheer
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 th
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 do
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
backe
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 c
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 pick filters for each {{variable}} by
> > > look
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 inside a
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.
Thank
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 explicitly affecting stat
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 s
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:
> Referring to Django's s
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:
> http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger
> I sat dow
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 'forms/layou
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 and main reason is, tha
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 ba
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 God
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, s
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
myhttp://garmoncheg.blogspot.com/2011/0
31 matches
Mail list logo