First off, for some arcane reason Google is forcing formatting on me.
Hopefully that doesn't make this email that ugly.
Anyway, as the current lead on Django Uni-Form I think its great that Gregor
is picking up the torch for refactoring form rendering in Django 1.40. He's
obviously done his
Haven't got time for a full review of this proposal right now, but I've done
a lot of thinking about this area already and am more than happy for anyone
to steal my ideas and compare thoughts.
Shoot me an email off-list or catch me on #django (as SmileyChris) if you
want to discuss more
On Sun, Apr 3, 2011 at 2:52 PM, Carl Meyer wrote:
> Hi Michal,
>
> On 04/01/2011 09:22 PM, Michal Petrucha wrote:
> > I propose to implement a CompositeField with the following properties:
> >
> > - will be represented as a namedtuple containing the values of the
> > actual
Hi Michal,
On 04/01/2011 09:22 PM, Michal Petrucha wrote:
> I propose to implement a CompositeField with the following properties:
>
> - will be represented as a namedtuple containing the values of the
> actual fields it encapsulates
>
> - will support retrieval and assignment (assignment
Hi,
2011/4/2 Russell Keith-Magee :
> On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger
> wrote:
>> I suggest reading this proposal online: https://gist.github.com/898375
>> It's exactly the same as below but formated nicely.
>>
>>
>> GSoC 2011
It's not very obvious from the docs or source if HttpRequest.read() can
always be safely treated as a limited input stream, or if the developer
needs to respect HttpRequest.META['CONTENT_LENGTH'].
As far as I can tell the intention is that it can always be treated as a
limited stream, that
Hi Yuri,
thanks for your toughts.
2011/4/2 burc...@gmail.com :
> Gregor,
>
> Regarding proposal itself,
>
> the idea to make django form rendering based on templates is good, but
> I think it should be simple, modular and not much verbose.
> I'd like more to see more modular,