I posted a bug (http://code.djangoproject.com/ticket/3280) before I
left work which quickly got shot down by Adrian. :) He's right in
that it's a pretty general bug so I bring the conversation here. I'm
curious what the Django devs will make of my reasoning...
I realize some of these aren't di
Rob Hudson schrieb:
> I realize some of these aren't directly related to whether Django
> itself prefers XHTML. Some are more along the lines of how easy it
> should be to work around Django if you prefer HTML4.
>
> The following are what I think are valid reasons why Django should be
> HTML agn
Rob Hudson wrote:
>
> 1. Display code should be separate from logic. Ideally, all HTML would
> be in template files that one could override if need be in their own
> template directory, just like the admin templates. If django.forms did
> this, that would be great.
The forms framework I wrote out
Michael Radziej wrote:
> I'm not sure what you mean exactly with "HTML agnostic". Could you
> explain it, please?
Just that Django shouldn't favor XHTML over HTML4. But I'm actually
not too concerned if it comes with django.forms that default to XHTML,
but they are easily configurable or easy to
On 1/11/07, Andrew Durdin <[EMAIL PROTECTED]> wrote:
>
> Rob Hudson wrote:
> >
> > 1. Display code should be separate from logic. Ideally, all HTML would
> > be in template files that one could override if need be in their own
> > template directory, just like the admin templates. If django.forms
On 1/11/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> However, if there was a way to pass final_attrs for each
> field in a form to the template (perhaps as an optional behavior),
> that would give template authors complete control over the layout of
> their forms.
I thing I approached that ki
On 1/11/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> It should be easy to see that passing final_attrs into Andrew's
> template would give the desired result (perhaps with a few
> adjustments. It shouldn't be to hard for someone to hack up such a
> variation. Then when defining the form, just p
I think it's in the other thread, but what's the reason for wanting to
decouple forms from templates? I can think of 2 reasons:
1) Decoupling means you can change the way templates work and not have
to update the forms code. Counter argument: If you change the way
templates work you'd break a l
On 2007-01-11, Rob Hudson wrote:
>
> 2. The argument against #1 that I've seen is usually that you can
> subclass Something and write your own output. But in some ways, this
> violates the DRY principle. The code to output a form widget, for
> example, is already written, and in looking at what i
