Le 24/06/2011 01:02, Carl Meyer a écrit :
On 06/23/2011 04:43 PM, Jacob Kaplan-Moss wrote:
The wrong performance benchmarks could result in a veto from me; this
is important.
I really think templated form-rendering is a massive improvement in
Django for front-end devs, so I'm very hopeful that Armin's work can
make rendering speed a non-issue. No pressure, Armin ;-)
Carl
IMHO, templated form rendering is not an option, it already is a reality (and
performance already is an issue).
Templated form rendering is already a practice of several front-end devs:
* I believe many of us tried to include template snippets to be able to reuse
some form layouts (starting with {% include %})
* Since there is no de-facto convention for implementing the functionality
right now, everyone uses a personal recipe.
* There is no documentation about doing it right, with performances in mind.
* Maybe hundreds of front-end devs are doing it wrong because there is no
standard, with optimizations included.
I am currently using my own (shared) recipe for templated form rendering
(django-formrenderingtools) and I will keep using it until there is a standard
tool implementing such functionality.
For most websites I develop, I'd rather be able to develop them quickly with
nice reusable code than provide extreme performances.
For the websites which require high performances, I use the cache, and if it is
not enough, I can fallback to hard-coded form rendering.
So, in my case, hard-coded template form rendering is the option, whereas
templated form rendering is the standard.
Le 24/06/2011 06:42, Jjdelc a écrit :
Is it possible for a django user to overload {% formconfig %} to do
something else? or do we have to wait for a next Django release to
have new behavior?
I agree with Jjdelc: we should not be restricted to one hard-coded
implementation.
If someone has a solution to improve performance, or to match a project
specific needs, it should be possible to override the default.
Le 14/06/2011 11:38, Benoît Bryon a écrit :
Another idea: what if we got "layout loaders"?
FORM_LAYOUT_LOADERS = (
'my.custom.app.SelectLayoutMatchingUserPreferences',
'another.custom.app.SelectLayoutMatchingUrl',
'another.custom.app.SelectTemplateMatchingFieldHtmlName',
'django.forms.layouts.loaders.FallbackLayoutLoader',
)
Configurable loaders are one way to be flexible.
Implementing the form rendering with class-based components is another.
We already have Python classes for widgets. There could be a widget class which
does not use templates and provide extreme performance.
Why not Python classes for other form elements? It would make it possible to
implement both hard-coded and templated solutions.
It is a great practice in django-floppyforms: use Python components with a
render() method. So let's apply this pattern to all form elements!
Could the "layout" parameter be, in fact, a reference to a Python class?
Something like this (to be consistent with the {% widget %} syntax)::
{% form AsTableLayout for form %}
{% form AsTableLayout %}<!-- equivalent to the line above if "form" is the
convention for variable name -->
{% form %}<!-- equivalent to the line above if AsTableLayout is the default
-->
It should be possible to provide "generic" base classes which cover most of the
use cases.
And it would be possible to make hard-coded-high-performance layouts and
templated ones living together.
Benoit
--
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.
