Re: another ticket: related-object window is missing query ...
thanks adrian, I´ll use the trac-system next time ... Am 06.12.2006 um 07:24 schrieb Adrian Holovaty: > > On 10/26/06, patrickk <[EMAIL PROTECTED]> wrote: >> when doing a search in the related-object window in the admin- >> interface and using the link "xxx total" after that search, the query >> is missing. >> because "pop=1" is in the query, the header is shown ... > > Hi patrickk, > > I've fixed this in trunk in [4165]. Thanks for reporting! > > I almost missed your bug report, though, because it was posted to the > list rather than Trac. Give Trac another shot from now on; I think > we've fixed the eager spam-block issues. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session renewal: want a patch?
I like the idea. this way you can have a 'anonymous' user with the same session id for active users, and still have infrequent users removed from the session table. --Ian On 06/12/2006, at 5:15 PM, Adrian Holovaty wrote: > > On 11/8/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: >> Currently, sessions are renewed only if 1) they're modified or 2) >> every request. >> >> There's a middle ground that's useful: renew the session and >> cookie if >> it's within X days of the session's current expiration. This keeps >> cookies for unmodified sessions from expiring while not sending out a >> cookie on every request. >> >> Would you like a patch for that? Something like: > > I personally don't use sessions enough to have a strong opinion on > this, but I could see how some might find it useful. Any other > thoughts? > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > -- Ian Holsman [EMAIL PROTECTED] http://economy-chat.com It's what the economists talk about --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Help to translate
> 2006/12/5, mario__ <[EMAIL PROTECTED]>: > > This is my little help > > http://media.forestal.udec.cl/django/ > > > > Perhaps you want to use Django I18N mailing list for this kind of affairs. > Wow, I didn't know, I'm sorry. But, not should be l10n? in any case, where are they? > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Help to translate
> > Well, we could have the 'es' translation in 100% completed first and > > then start to think in another countries. The 'es' file is about 80% > > translated so if you let me I'll do my best to translate all the file. > > > > Where is this 'es' file perhaps you mean es_CL ? > In django source code django/conf/locale/es/LC_MESSAGES > > Is not my intention to start a flame war LOL but in Spain the correct > word for 'Computer' is 'Ordenador' AFAIK :) Trust me I really yes, you're rigth, the word could be 'Ordenador', so, it's much more weird :-) > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
New faster SelectBox.js
Dear django-devs, If you have thousands of entries in a multiple select box in the Django admin interface, the Javascript in SelectBox.js which makes the nice gui widget, runs too slowly, and the browser will complain. We have re-written SelectBox.js (attached or at http://django.pastey.net/3102) to use maps/objects where it used to use lists, changing the complexity of SelectBox.move from quadratic to linear (and I thought big O notation was just for interview questions!). For example on a list of 4000 elements it now iterates 4000 times instead of up to 16 Million (4000*4000). We've had this in production for 3 days now, and all seems well. I'll open a ticket as soon as code.djangoproject.com comes back (OperationalError: database is locked). - Could someone else try this out ? It's an important part of the admin interface and it's changed a lot. I'd like confirmation that it works fine for someone else before I officially submit it for consideration. - SelectBox has a 'sort' method. This didn't seem to be called anywhere. The new version calls it prior to displaying the options in the box, so options are always sorted alphabetically. This makes sense to me, but changes current behavior. What do you think ? Thanks, Graham. PS: If you have lots of elements in your select box, and your object has a FileField (meaning multipart encoding on your form), you might run into an intermittent bug Saving, whereby in http.__init__ on this line: name_dict = parse_header(submessage['Content-Disposition'])[1] parse_header gets give None. This is, believe it or not, a Python email package bug: http://sourceforge.net/tracker/index.php?func=detail&aid=170&group_id=5470&atid=305470 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~--- SelectBox.js Description: JavaScript source
Does anyone has seen toscawidgets
http://www.toscawidgets.org/ I think toscawidgets does not only aim for widgets, but also aims for plugable components. Anyone has any ideas? -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New faster SelectBox.js
Now with a ticket: http://code.djangoproject.com/ticket/3099 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Help to translate
> > Perhaps you want to use Django I18N mailing list for this kind of affairs. > > > > Wow, I didn't know, I'm sorry. But, not should be l10n? in any case, > where are they? > Look for the list on google groups. -- Iván Alemán --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New faster SelectBox.js
On 12/6/06, Graham King <[EMAIL PROTECTED]> wrote:
> PS:
> If you have lots of elements in your select box, and your object has a
> FileField (meaning multipart encoding on your form), you might run into
> an intermittent bug Saving, whereby in http.__init__ on this line:
>
> name_dict = parse_header(submessage['Content-Disposition'])[1]
>
> parse_header gets give None.
> This is, believe it or not, a Python email package bug:
> > http://sourceforge.net/tracker/index.php?func=detail&aid=170&group_id=5470&atid=305470
Christ, I've been trying half-heartedly to reproduce that for ages.
I just pinged the python bug to get it fixed.
I don't see a way to work around this without patching
email.message_from_string.
All, here's a traceback for the problem, for future searchers:
File "/pegasus/code/current/django/utils/httpwrappers.py", line 46,
in parse_file_upload
name_dict = parse_header(submessage['Content-Disposition'])[1]
File "/usr/lib/python2.4/cgi.py", line 331, in parse_header
plist = map(lambda x: x.strip(), line.split(';'))
AttributeError: 'NoneType' object has no attribute 'split'
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
This looks pretty cool. I'm excited by the new forms development and hope to play with some of it soon. It seems a little out of place to me to instantiate an object in urls.py: (r'^post/$', MyFormPreview(MyForm)), (There was some thread talking about urls.py becoming more of a "controller", but I never followed up on understanding that idea fully.) -Rob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New faster SelectBox.js
Graham King wrote: > If you have thousands of entries in a multiple select box in the > Django admin interface, the Javascript in SelectBox.js which makes the > nice gui widget, runs too slowly, and the browser will complain. if I had to use a multi-selection box with thousands of entries in it, I'd probably run around and complain too. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New faster SelectBox.js
On 12/6/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > nice gui widget, runs too slowly, and the browser will complain. > > if I had to use a multi-selection box with thousands of entries in it, > I'd probably run around and complain too. > The filter_interface makes it much less painful. :) I'm wavering about doing an auto-complete, but I think those make the assumption that a user will know what to start typing. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
On 12/6/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > A well triaged patch has the following characteristics: > One more thing that I forgot - if the patch adds a new feature, or a new option, there needs to be documentation of that feature (or at the very least, a decent first draft that the committers can massage into shape). If you feel that your english skills aren't up to writing documentation, ask around on the list; you might find someone with good english skills, but less advanced technical skills that is willing to help out. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
On 12/6/06, limodou <[EMAIL PROTECTED]> wrote: > > > [1] Note that 'non-trivial' doesn't just mean 'only affects 1-2 lines > > of code' - it also includes the fact that the lines that are being > > modified don't have a significant follow-on effect on the overall > > design of Django. > > > All above are aimed to submitter, I think that are very good. But I > hope that the developers of django team should do something. For > example simply close them, it means that these tickets be reviewed. I'm unclear as to what it is that you think the developers are (or are not) doing. If I find a ticket that I determine to be incorrect, I close it. If I fix a bug, I close the ticket. The tickets that are open are open for a reason - nobody has had the time to address them. The purpose of triage is to process these open tickets. Part of the triage process is to determine if the problem actually exists at all - if, as a result of triage, you determine that a bug report is straight out wrong, then close it. If you are uncertain, report the ticket to django-developers for discussion, and make a recommendation. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multipart email support
On 12/6/06, Sergey Kirillov <[EMAIL PROTECTED]> wrote: > > URL: http://code.djangoproject.com/ticket/1541 > > Can someone integrate it into trunk? Read the thread on the ticket - Jacob has stated what is standing between the ticket and acceptance - documentation of the feature. Write some documentation (or at least get an intitial draft ready), add it to the patch, and we can get this feature into the trunk. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
Awesome. Thanks for the feedback Russell. I've been involved in bug-triage with Ubuntu and Gnome ... and what you're saying is right in line with what I would have done for them. I just wanted to be certain that I wasn't stepping on toes. Lakin On 12/6/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > On 12/6/06, limodou <[EMAIL PROTECTED]> wrote: > > > > > [1] Note that 'non-trivial' doesn't just mean 'only affects 1-2 lines > > > of code' - it also includes the fact that the lines that are being > > > modified don't have a significant follow-on effect on the overall > > > design of Django. > > > > > All above are aimed to submitter, I think that are very good. But I > > hope that the developers of django team should do something. For > > example simply close them, it means that these tickets be reviewed. > > I'm unclear as to what it is that you think the developers are (or are > not) doing. If I find a ticket that I determine to be incorrect, I > close it. If I fix a bug, I close the ticket. The tickets that are > open are open for a reason - nobody has had the time to address them. > > The purpose of triage is to process these open tickets. Part of the > triage process is to determine if the problem actually exists at all - > if, as a result of triage, you determine that a bug report is straight > out wrong, then close it. If you are uncertain, report the ticket to > django-developers for discussion, and make a recommendation. > > Yours, > Russ Magee %-) > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
On 12/7/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 12/6/06, limodou <[EMAIL PROTECTED]> wrote: > > > > > [1] Note that 'non-trivial' doesn't just mean 'only affects 1-2 lines > > > of code' - it also includes the fact that the lines that are being > > > modified don't have a significant follow-on effect on the overall > > > design of Django. > > > > > All above are aimed to submitter, I think that are very good. But I > > hope that the developers of django team should do something. For > > example simply close them, it means that these tickets be reviewed. > > I'm unclear as to what it is that you think the developers are (or are > not) doing. If I find a ticket that I determine to be incorrect, I > close it. If I fix a bug, I close the ticket. The tickets that are > open are open for a reason - nobody has had the time to address them. I suggest developers should periodically check the patches, and I saw many patched were discussed at the first, and some just don't be discussed at all, they just exist in the report, it seems that no one has the time to review them. And for submitter, they of cause want the tickets be accepted, and that's a way of contribution to djano, and I think they like that. But they may don't do as well as what you described, but I think if the developer consider it's useful, and want to accept it, why not ask the submitter give more details? Or we can have a detail form for submitter, they can fill the form and let the ticket can be accepted or discussed easily. And I think many submitter like to discuss their tickets. Even though the tickets may not be accepted at all. -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
On 12/7/06, limodou <[EMAIL PROTECTED]> wrote: > > On 12/7/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > On 12/6/06, limodou <[EMAIL PROTECTED]> wrote: > > > > > > > [1] Note that 'non-trivial' doesn't just mean 'only affects 1-2 lines > > > > of code' - it also includes the fact that the lines that are being > > > > modified don't have a significant follow-on effect on the overall > > > > design of Django. > > > > > > > All above are aimed to submitter, I think that are very good. But I > > > hope that the developers of django team should do something. For > > > example simply close them, it means that these tickets be reviewed. > > > > I'm unclear as to what it is that you think the developers are (or are > > not) doing. If I find a ticket that I determine to be incorrect, I > > close it. If I fix a bug, I close the ticket. The tickets that are > > open are open for a reason - nobody has had the time to address them. > > I suggest developers should periodically check the patches, and I saw > many patched were discussed at the first, and some just don't be > discussed at all, they just exist in the report, it seems that no one > has the time to review them. We _do_ check the patches. My RSS reader subscribes to the Django Tickets and Django Changes RSS feeds, so I am notified whenever a ticket is opened or closed. I give almost every ticket a quick read. If I see a suggestion that is _obviously_ wrong, I will close the ticket. If I a ticket has a _really_ trivial fix, _and_ I have the time, I will apply the fix and close the ticket. However, there are literally not enough hours in the day for the core developers to hold down a job, keep our wives, children and families happy, AND do a full and comprehensive review on every single bug ticket that is lodged. > And for submitter, they of cause want the > tickets be accepted, and that's a way of contribution to djano, and I > think they like that. But they may don't do as well as what you > described, but I think if the developer consider it's useful, and want > to accept it, why not ask the submitter give more details? Or we can > have a detail form for submitter, they can fill the form and let the > ticket can be accepted or discussed easily. This is what the triage process is all about. The developers aren't the only people that can do what you are asking. Anyone can ask a submitter for more details - the ticket system already has the ability to add comments to a ticket; there is a user mailing list; many people put their personal email addresses on tickets. If you want to help out, pick a ticket that looks interesting, and triage. Try to replicate the reported problem. Ask the submitter for more details if they are required. Try to understand the patch that has been suggested. And report back to django-developers when the ticket is in a state that it requires a yes/no from a committer. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
On 12/7/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 12/7/06, limodou <[EMAIL PROTECTED]> wrote: > > > > On 12/7/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > > > On 12/6/06, limodou <[EMAIL PROTECTED]> wrote: > > > > > > > > > [1] Note that 'non-trivial' doesn't just mean 'only affects 1-2 lines > > > > > of code' - it also includes the fact that the lines that are being > > > > > modified don't have a significant follow-on effect on the overall > > > > > design of Django. > > > > > > > > > All above are aimed to submitter, I think that are very good. But I > > > > hope that the developers of django team should do something. For > > > > example simply close them, it means that these tickets be reviewed. > > > > > > I'm unclear as to what it is that you think the developers are (or are > > > not) doing. If I find a ticket that I determine to be incorrect, I > > > close it. If I fix a bug, I close the ticket. The tickets that are > > > open are open for a reason - nobody has had the time to address them. > > > > I suggest developers should periodically check the patches, and I saw > > many patched were discussed at the first, and some just don't be > > discussed at all, they just exist in the report, it seems that no one > > has the time to review them. > > We _do_ check the patches. My RSS reader subscribes to the Django > Tickets and Django Changes RSS feeds, so I am notified whenever a > ticket is opened or closed. I give almost every ticket a quick read. > If I see a suggestion that is _obviously_ wrong, I will close the > ticket. If I a ticket has a _really_ trivial fix, _and_ I have the > time, I will apply the fix and close the ticket. > > However, there are literally not enough hours in the day for the core > developers to hold down a job, keep our wives, children and families > happy, AND do a full and comprehensive review on every single bug > ticket that is lodged. > > > And for submitter, they of cause want the > > tickets be accepted, and that's a way of contribution to djano, and I > > think they like that. But they may don't do as well as what you > > described, but I think if the developer consider it's useful, and want > > to accept it, why not ask the submitter give more details? Or we can > > have a detail form for submitter, they can fill the form and let the > > ticket can be accepted or discussed easily. > > This is what the triage process is all about. The developers aren't > the only people that can do what you are asking. Anyone can ask a > submitter for more details - the ticket system already has the ability > to add comments to a ticket; there is a user mailing list; many people > put their personal email addresses on tickets. > > If you want to help out, pick a ticket that looks interesting, and > triage. Try to replicate the reported problem. Ask the submitter for > more details if they are required. Try to understand the patch that > has been suggested. And report back to django-developers when the > ticket is in a state that it requires a yes/no from a committer. > > Yours, > Russ Magee %-) > Thank you. I want to help, but I'm only a user, so my skills are limited in some fileds, and I may only care about what I'm interesting in. So I think some user indeed can provide some useful help. But you know they don't know much and deeper like developers, and the they also don't have the rights to submit the patches. So the attention I think is quite deconcentration. For example, there is a ticket which I'm interested in, and I indeed give some advices, but there maybe only one poll to it, if there is no other users interested in it. This ticket will still be delayed. -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
Next on the list should be a Login form. Should be very simple. On 12/5/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Adrian Holovaty wrote: > > > What other sorts of things can we make abstractions for, > > > given a Form? > > > > First thing that comes to mind is the same thing you describe but > > without preview. In other words it's what update_object generic view > > does now but it works only on models and often it is desired to work > > this way with arbitrary form. But I'm sure you've already thought about > > it... > > Yes, *definitely*...That one is next on the list. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
On 12/6/06, Brantley Harris <[EMAIL PROTECTED]> wrote: > Next on the list should be a Login form. What would you envision for that? Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Re: Default representation of a Form
On 12/1/06, James Bennett <[EMAIL PROTECTED]> wrote: > So maybe an as_dl() method needs to go in? With as_dl(), how would error messages be displayed? Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Default representation of a Form
On 11/30/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > A new Form class' default representation (that is goes out of `print f`) > is an HTML table. For those who cares about that proverbial 'semantics' > thing this looks wrong. From the practical point of view it's also not > very convenient since it (for example) doesn't allow to layout the form > in different ways: labels above widgets, labels to the left of widgets, > labels and widgets in one string etc. > > Instead I suggest this default representation: > > >Field name > > I've implemented Form.as_p() in [4178]. The differences between my implementation and your proposal are that I didn't give the an "id" attribute, and the errors get displayed in a above the , rather than after the field. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
