Re: [GSoC] Revised form rendering
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, but easier syntax:
> 1) If you have to render form in your custom way, you have to write
> all form fields (you'll tweak their order and widgets anyway later, so
> it's a plus).
> 2) If you have to render field in your custom way, you have to write
> your own widget or widget template.
> 3) Any advanced form customization can be made using templates.
>
> Something like this:
> {% renderform form1 using layout "uni_form" %} {# errors output could
> be changed with layout templates only #}
> {# will use template layouts/app1/uni_form/charfield/x.html if it
> was charfield. #}
> {% render field1 using widget template "x" set class="field1" %}
> {% render field3 %}
> {% render field2 %}
> {% endrenderform %}
If I get your ideas right, then my proposed {% form %} and {% formblock %}
tag already supports what you suggested. I try to rewrite your example with
my proposed syntax:
{% formblock form1 using layout "uni_form" %}
{% form form1.field1 using widget template "x" and addclass "field1" %}
{% form form1 using fields "field3" "field2" %}
{% endformblock %}
The things that are different to your example are just some minor syntax
things. Additionally, the "rendering modifiers" (in this case "widget" and
"addclass") are not specified yet and I don't settled on a fixed set yet. I
would like to defer this until a later point because thats something that need
a broader discussion and IMO shouldn't take place in this thread, discussing
the more basic concerns regarding my proposal.
Or did I misunderstand what you tried to express? If thats the case, sorry for
that and please clarify that for me. I would appreciate your feedback.
(btw: a difference to your example is that I use the form tag to render forms
and single fields. I will include why I choose to do this in my response later
to Russell's post -- sorry I need to get offline but will respond again in the
next few hours)
--
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.
HttpRequest.read() issues
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 seems to at least be the implication in
WSGIRequest.__init__, in which case it looks to me like there are two bugs.
1. This code should not raise an Assertion Error...
>>> from django.test.client import RequestFactory
>>> req=RequestFactory().post('/', {'foo':'bar'})
>>> req.read()
Traceback (most recent call last):
File "", line 1, in
File
"/Users/tomchristie/workspace/django-rest-framework/env/lib/python2.6/site-packages/django/http/__init__.py",
line 296, in read
return self._stream.read(*args, **kwargs)
File
"/Users/tomchristie/workspace/django-rest-framework/env/lib/python2.6/site-packages/django/test/client.py",
line 51, in read
assert self.__len >= num_bytes, "Cannot read more than the available
bytes from the HTTP incoming data."
AssertionError: Cannot read more than the available bytes from the HTTP
incoming data.
After all, running under the dev server I can do this just fine without
causing an exception:
def test(request):
return HttpResponse("Read data: '%s'\n" % request.read())
(In the first case the underlying stream isn't being wrapped in a
LimitedStream, in the second case it is)
2. Isn't the use of LimitBytes in MultipartParser.parse() now redundant?
If it isn't the intention that HttpRequest.read() can be treated as a
limited stream then shouldn't this be documented, and in any case wouldn't
it be better if it was always a limited stream - there's some
duplicated behavior with parsing the CONTENT_LENGTH in WSGIRequest,
HttpRequest and MultipartParser that looks like ti could be avoided.
Am I just fundamentally misunderstanding something?
Cheers,
Tom
--
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.
Re: [GSoC] Revised form rendering
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 Proposal - Revised form rendering
>>
>>
>> Hi my name is Gregor Müllegger. I'm a Computer Science student in Germany at
>> the University of Augsburg currently in the fourth year of my studies. I
>> first
>> came to django shortly before 0.96 was released and a lots of awesomeness was
>> introduced with the magic removal branch.
>
> Hi Gregor,
>
> Firstly, I'd like to echo Carl's sentiments -- this is a strong
> proposal that shows you've researched the history of Django
> discussions on this topic, and given it some thought of your own.
>
> Carl has already raised several of the points that I noticed on my
> read through. However, I do have some of my own queries.
>
> Syntax
> ~~
>
> You've proposed a syntax that goes something like:
>
> {% form myform using layout "p" and fields "firstname" "lastname" %}
> {% form fancyform.favourite_color using layout "p" %}
>
> I have two questions about this syntax.
>
> Firstly, while it looks fine for a small example, I can see how it
> would rapidly deteriorate if you have lots of fields, or lots of
> custom field requirements for each field. Django's template language
> doesn't allow you to split tags over multiple lines, so what happens
> when my tag runs over 80 characters (this simple example is already a
> 69 characters)?
(Having the possibility of multiline tags would be nice in many other cases as
well ... but that's another topic :-)
I don't see the use of more than two or three modifiers in a template tag in a
day to day use. However it's ofcourse possible to produce complex statements
that would need to span multiple lines. And it's already possible with the
syntax described in the proposal.
You can use a {% formblock %} to extract the modifiers out of the form tag:
{% formblock using layout "uni_form" %}
{% formblock using widget template "calendar" for myform.birthday %}
{% form myform using fields "firstname" "lastname" "birthday" %}
{% endformblock %}
{% endformblock %}
Some might not like the syntax since you would encourage another level of
indention and another two lines for the closing tags. But you can use the
"configure" statement as described in the media handling section of my
proposal:
{% form myform configure layout "uni_form" %}
{% form myform configure widget template "calendar" for myform.birthday %}
{% form myform using fields "firstname" "lastname" "birthday" %}
> Secondly, you appear to be using a single template tag for rendering
> both forms *and* fields. Is there a motivation behind this?
Yes there is :-) The motiviation is, that {% form myform.birthday %} is just a
shorthand for {% form myform using fields "birthday" %}. You can also use it
to iterate over a form (like in your example below) and outputting it field by
field:
{% for field in myform %}
{% form field %}
{% endfor %}
I also don't see a need for an extra {% formfield %} tag. I don't see any
cases in which a {% formfield %} would be shorter, more flexible, easier to
use. It might be more readable, but I think it would end up as a stripped down
copy/alias of the form tag.
> Rendering modifiers
>
>
> I share Carl's concern about exactly how and why these are necessary;
> even after your most recent post, I'm still not completely clear on
> what they mean in practice.
>
> On the one hand, I can see that there may be a use case for passing
> arguments into the template rendering process. However, you seem to be
> proposing a mechanism by which developers could define Python code
> that alter widget rendering by performing such tasks as:
>
> * selecting a different rendering directory
> * changing the template that is used for a widget
> * changing the layout scheme
> * prepending/appending content onto a widget
>
> I think I understand your motivation here, but my inclination is that
> this will end up being a very complex system that won't end up being
> useful in practice.
The rendering modifiers came up in the proposal because I thought about the
possible implementations of the {% form ... using ... and ... %} syntax. I had
the idea that these modifiers after "using" could be seperated from the tag
itself. I had the analogy to queryset methods in mind. E.g. the filter() method
changes the internal state of the queryset. The same would be true for
rendering modifiers, analogy: the "fields" modifiers limit the rendered
fields. These modifiers could be implemented easily as methods on the template
tag.
But with querysets you can extend the QuerySet base class and add other
convenience methods. I wanted the same for the form rendering. Why shouldn't
it be possible not only to use the rendering mod
Re: [GSoC] Composite fields
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 sets the values of > encapsulated fields) > > - will be possible to use in __exact QuerySet lookups > > - support for Field.db_index and Field.unique creating the appropriate > indexes and constraints in the database > > - support for Field.primary_key I haven't had time yet to sit down and look at your implementation questions for a CompositeField (how it works with lookups and Qs, etc), but I do think that one design goal for a CompositeField implementation is that we should be able to reimplement the Generic Foreign Key as a CompositeField. I think your proposal could get there fairly easily -- all that's needed is for the mapping to and from the Python representation to be customizable by a CompositeField subclass. So a namedtuple representation is a sane default, but a GFK implementation could override that to map to and from actual model objects instead. Carl -- 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.
Re: [GSoC] Composite fields
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 fields it encapsulates > > > > - will support retrieval and assignment (assignment sets the values of > > encapsulated fields) > > > > - will be possible to use in __exact QuerySet lookups > > > > - support for Field.db_index and Field.unique creating the appropriate > > indexes and constraints in the database > > > > - support for Field.primary_key > > I haven't had time yet to sit down and look at your implementation > questions for a CompositeField (how it works with lookups and Qs, etc), > but I do think that one design goal for a CompositeField implementation > is that we should be able to reimplement the Generic Foreign Key as a > CompositeField. I think your proposal could get there fairly easily -- > all that's needed is for the mapping to and from the Python > representation to be customizable by a CompositeField subclass. So a > namedtuple representation is a sane default, but a GFK implementation > could override that to map to and from actual model objects instead. > > Carl > > -- > 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. > > Like Carl I haven't had time to properly read this, but one important thing (IMO) to think about is not just having composite field support, but support for "virtual" fields in general, that is fields that don't map to a database column. This is for things like serialization, querying, forms, etc. (you know all the places we use metadata). Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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.
Re: [GSoC] Revised form rendering
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 personally. -- 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.
Re: [GSoC] Revised form rendering
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 homework and put a lot of thought into this critical part of Django. I'm not a core developer my vote doesn't count, but I'm giving it anyway. +1 from me. Daniel Greenfeld pyda...@gmail.com -- 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.
