Re: Patches, Tests and All the Rest
Hi Russell, Russell Keith-Magee wrote: > ... > Obviously, simple changes are no brainers. However, if a patch is a > deep change, I (as a developer) need to be convinced: > 1) That the problem actually exists > 2) That the proposed fix is the right approach to solve the problem > (e.g., there are lots of patches for Manipulators at the moment - but > the right fix is to get rid of them altogether) > 3) That the proposed fix is correct > > Submitting a big, deep patch (even if it is tested) is a very small > part of this - the dialog that surrounds the patch is equally > important. This means a clear statement of the problem in the ticket > itself, and evidence of some discussion of alternatives that has > engaged the committers. > > Again, this is an area where a triage team could be a lot of help - > checking big patches, kick-starting discussion for tickets that are > worthy of deeper examination, etc. I'm so for this! +1! I think some people who really take care of the tickets would help a lot with these problem. Thanks for your positive and friendy response to my points. Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Merquery patches
Hi again, I've finished my work for now, it's working fine. Please, someone look the patch3.diff and apply the differences into theirs respectives files http://code.djangoproject.com/ticket/2707 Thanks-- SDM UnderlinuxGarimpar.com--PEP-8"Mais vale um ponteiro na mao do que duas classes voando"CPFL - Compania Piratininga de FALTA de Luz (6 vezes em 5 dias!!) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
On Tue, 2006-09-12 at 14:35 -0500, Adrian Holovaty wrote:
> The template would look like this:
>
>
> {% if form.sendername.errors
> %}{{ form.sendername.errors.as_ul }}{% endif %}
> Your name: {{ form.sendername.as_text }}
>
> {% if form.senderemail.errors %}{{ form.senderemail.errors_as_ul
> }}{% endif %}
> Your e-mail: {{ form.senderemail.as_text }}
>
> {% if form.subject.errors %}{{ form.subject.errors.as_ul }}{%
> endif %}
> Subject: {{ form.subject.as_text }}
>
> {% if form.message.errors %}{{ form.message.errors.as_ul }}{%
> endif %}
> Message: {{ form.message.as_textarea }}
>
>
>
Alas, it seems I'm the only one wanting to have the form framework
handle buttons as well.
Now I'm not asking for the Form to automatically have submit buttons,
what I'm asking for is to be able to have a ButtonField or
GroupOfButtonsField .
Example:
I just finished working on a multi-page form that uses three
with values value="<
prev" value="next >" and value="cancel"
The value of request.POST["action"] always has the correct
value. [1] That is, the value for the button that was clicked.
So I'm able to use it in processing.
This value though, is the only one not handled by the
Manipulator.
Now I see in this new Form thing, you're ignoring buttons completely.
Am I wrong to assume that the value of the button clicked can be
important? Or is it not important enough?
/Marc DM
[1] I tested it in Firefox 1.5 and Epiphany on Gnome 2.14 and IE6 and
IE4.01 on Win2k. In ie4, I had to remove the styling from the buttons so
I could click them but they submit the correct value. Contrary to what I
heard in #django
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Proposal: Forms and BoundForms
On 9/13/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> >
> > On 14/09/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
>
> > > For instance, using the given example:
> > >message = TextField(label='Your message',
> > > attributes={'class':'vRichTextField'})
> > >
> >
> > +1 on this for me. I'd love to be able to do:
> >
> > author = SelectField(attributes={'dojoType': 'Select'})
>
> Agreed on the need, not on the implementation.
>
> [...]
>
> IMHO, a better approach would be to allow rendering extensions to be
> registered on the field itself; e.g.,
>
> author = SelectField(extra_renderers={'dojo':dojo_renderer,
> 'brantley':brantley_renderer})
>
I think this is needlessly complicated and impractical. Remember that
the renderer is the ultimate decider on what to do with the field's
properties, so if the renderer doesn't trifle with 'attributes' or
'label', it doesn't have to. Also, I support a default renderer (for
simplicity), but I don't support multiple renderers for a field class;
I think that is the realm of templatetags-- It is responsible for the
rendering of data after all, not the structure or logic of the data.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: RequiredIfOtherFieldsGiven validator
Hi Andy, Yep, this little corner of the validator module is a bit messy. I ran into exactly the problems you describe. It turns out that Matt Rigott first reported problems in this area in June, along with a patch. I noticed in July, updated the patch, and added unit tests (very topical!) I've been a bit wary of pestering Adrian, Jacob et. al. to apply the patch, given their current workloads. However, if you could have a look at the patch and comment and/or fix, then that would definitely help get these problems fixed. http://code.djangoproject.com/ticket/2266 Cheers, Alan. On 9/14/06, Andy Dustman <[EMAIL PROTECTED]> wrote: > > I noticed (after inferring it probably exists) the > RequiredIfOtherFieldsGiven validator, though it is currently > undocumented. The default error message is, "Please enter both fields > or leave them both empty." The actual test is: > > def __call__(self, field_data, all_data): > for field in self.other: > if all_data.get(field, False) and not field_data: > raise ValidationError, self.error_message > > Since field_data is a constant, this is equvalent to: > > def __call__(self, field_data, all_data): > if field_data: return > for field in self.other: > if all_data.get(field, False): > raise ValidationError, self.error_message > > i.e. if this field is set, then if any of the other fields are not > set, it's invalid. So the error message is wrong or there's a bug. > Based on the name of the validator, I think the problem is in the > error message. It should be more like "Please either enter this field > or leave the other ones empty." > > What I actually need for my app is OnlyIfOtherFieldsGiven, which in > fact is what the RequiredIfOtherFieldsGiven validation error claims to > be doing. The test for OnlyIfOtherFieldsGiven would be: > > def __call__(self, field_data, all_data): > for field in self.other: > if bool(all_data.get(field, False)) ^ bool(field_data): > raise ValidationError, self.error_message > > (Yes, bitwise-exclusive-or actually will work on booleans.) > > If there's some interest in actually having this in Django, let me > know and I'll write up a ticket with patch. > -- > This message has been scanned for memes and > dangerous content by MindScanner, and is > believed to be unclean. > > > > -- Alan Green [EMAIL PROTECTED] - http://bright-green.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 -~--~~~~--~~--~--~---
Re: Serious problems with the way Django handles file uploads
On 9/13/06, jp <[EMAIL PROTECTED]> wrote: > http://paste.e-scribe.com/1564/ > http://paste.e-scribe.com/1565/ It's hard to infer exactly what's going on without knowing more about the actual code you're using; for example, that first set of profiler output is spending over 40% of its time in django.core.mail and related Python email modules, yet AFAIK there's nothing in FileField or the automatic manipulator for a model with a FileField which should get into that code. Could you provide some more detail about what your code is doing, especially anything it's trying to do with respect to sending email? -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Serious problems with the way Django handles file uploads
It isn't using FileField, infact it isn't touching the DB or using any kind of manipulator at all. The form consists of a simple box which allows the user to upload a file. The file is then submitted in a POST request to the second view. The second view then calls to an outside library which converts the file to a tab-delimited file, then the view continues on and does statistical work. None of my code has anything to do with the mail or email stuff. It is worth noting that parse_file_upload in django.http uses those email and mail libraries a lot. For what I don't know. But like I said, Im not calling to the DB or doing anything else. Really all Django itself is doing is uploading the file and then displaying a template. James Bennett wrote: > On 9/13/06, jp <[EMAIL PROTECTED]> wrote: > > http://paste.e-scribe.com/1564/ > > http://paste.e-scribe.com/1565/ > > It's hard to infer exactly what's going on without knowing more about > the actual code you're using; for example, that first set of profiler > output is spending over 40% of its time in django.core.mail and > related Python email modules, yet AFAIK there's nothing in FileField > or the automatic manipulator for a model with a FileField which should > get into that code. > > Could you provide some more detail about what your code is doing, > especially anything it's trying to do with respect to sending email? > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Serious problems with the way Django handles file uploads
On Sep 14, 2006, at 9:41 PM, jp wrote: > > It is worth noting that parse_file_upload in django.http uses those > email and mail libraries a lot. For what I don't know. Django uses the email libraries to parse the uploaded content as HTTP uses MIME encoding for file uploads. Don --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Serious problems with the way Django handles file uploads
On 9/14/06, jp <[EMAIL PROTECTED]> wrote: > It is worth noting that parse_file_upload in django.http uses those > email and mail libraries a lot. For what I don't know. Yeah, I just realized that; I didn't poke deeply enough. I'm pretty certain that's because file uploads (typically) come in as "multipart/form-data", which means the easiest way to parse them is with email-handling libraries (since they speak MIME natively). -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
