Re: Feature proposal: Test client form value extraction
Hi,
some time ago I wrote a snippet which does this:
http://www.djangosnippets.org/snippets/467/
{{{
If you want to test a post request to a form, you need to give all input
fields, even if you just want to test if one
value gets changed.
This snippets parses the HTML of a view and gives you a dictionary that you can
give to django.test.Client.
Needs ClientForm from: http://wwwsearch.sourceforge.net/ClientForm/
}}}
Joshua Russo schrieb:
> I've just put together an enhancement of the test Client used in unit
> testing. I added the parsing of the content to extract the form fields with
> their initial values as a dictionary, so you can just change a few values
> and throw it back at the server.
> http://dpaste.com/hold/85281/
>
> I had to do a small monkey patch to get it to work because direct override
> of the __ call __ method interfered with the transaction management for some
> reason.
>
> Let me know what you think. Should I submit it as a ticket?
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--~--~-~--~~~---~--~~
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: Feature proposal: Test client form value extraction
I figured someone had done this at some time.
What's the general consensus on when some thing like this should
be considered to be added to the project and when it should just stay as an
outside utility?
On Wed, Aug 26, 2009 at 7:11 AM, Thomas Guettler wrote:
>
> Hi,
>
> some time ago I wrote a snippet which does this:
>
> http://www.djangosnippets.org/snippets/467/
>
> {{{
> If you want to test a post request to a form, you need to give all input
> fields, even if you just want to test if one
> value gets changed.
>
> This snippets parses the HTML of a view and gives you a dictionary that you
> can give to django.test.Client.
>
> Needs ClientForm from: http://wwwsearch.sourceforge.net/ClientForm/
> }}}
>
>
> Joshua Russo schrieb:
> > I've just put together an enhancement of the test Client used in unit
> > testing. I added the parsing of the content to extract the form fields
> with
> > their initial values as a dictionary, so you can just change a few values
> > and throw it back at the server.
> > http://dpaste.com/hold/85281/
> >
> > I had to do a small monkey patch to get it to work because direct
> override
> > of the __ call __ method interfered with the transaction management for
> some
> > reason.
> >
> > Let me know what you think. Should I submit it as a ticket?
>
> --
> Thomas Guettler, http://www.thomas-guettler.de/
> E-Mail: guettli (*) thomas-guettler + de
>
> >
>
--~--~-~--~~~---~--~~
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: FileFields and file ownership
On Aug 11, 1:39 pm, Ole Laursen wrote: > 1) a convenient file pointer for facilitating the upload machinery > 2) a field for storing a file, just like storing it directly in the > database except we put the data in the file system No conclusion? Here are some options 1. Apply the patch in 11663 more or less as is. Pros: no API breakage. Cons: all FileField objects are leaking unless you do something. Deleting an object with a FileField causes full table scan (unless you add an index yourself). 2. Apply the patch, but turn on orphan deletion by default. Pros: FileField is leak-free out of the box. Cons: API break if you were relying on the garbage, deleting still causes full table scan. 3. FileField owns the file it points to. Pros: no leak, simple code, no table scans. Cons: API break if you were relying on two objects pointing to the same file. 4. As 3, but add option to be more in line with current behaviour. So API break, but it's easy to fix. Ole --~--~-~--~~~---~--~~ 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: Feature proposal: Test client form value extraction
On Wed, Aug 26, 2009 at 4:41 PM, Joshua Russo wrote:
> I figured someone had done this at some time.
> What's the general consensus on when some thing like this should
> be considered to be added to the project and when it should just stay as an
> outside utility?
It's certainly worth putting up as a ticket. I can agree with the
original use case - that is, using the client.get() to construct the
prototype data dictionary that will be passed to client.post(). You
only have to look at the work that is done in the admin tests to see
the value in this proposal.
However, I have some reservations about the patch.
Most notably, I'm not sure I see how your patch answers the original
use case. The form data structure that is returned by the parser
appears to contain a top-level dictionary containing the form
instances. The form structure itself is irrelevant to reposting.
However, thats not to say that keeping the form data is irrelevant.
For example, consider the case where a page has multiple forms, or
multiple submit buttons on a single form. If we're going to introduce
a utility like this, then it should be able to behave at least
partially like a browser - that is, I should be able to get the post
data that is needed to respond to a specific button press:
response = self.client.get('/path/to/page')
# Get a copy of a data dictionary that contains the form data
# that would be submitted if I pressed the submit button labeled 'button 3'
data = response.form_data('button 3')
data['some-field'] = 'new value'
response = self.client.post('/path/to/page', data)
We also need to be careful of feature creep - this sort of testing is
exactly what Twill does, and we don't want to duplicate the efforts of
that project (or any other automated Python client test framework for
that matter).
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Feature proposal: Test client form value extraction
On Wed, Aug 26, 2009 at 12:52 PM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:
>
> On Wed, Aug 26, 2009 at 4:41 PM, Joshua Russo
> wrote:
> > I figured someone had done this at some time.
> > What's the general consensus on when some thing like this should
> > be considered to be added to the project and when it should just stay as
> an
> > outside utility?
>
> It's certainly worth putting up as a ticket. I can agree with the
> original use case - that is, using the client.get() to construct the
> prototype data dictionary that will be passed to client.post(). You
> only have to look at the work that is done in the admin tests to see
> the value in this proposal.
>
> However, I have some reservations about the patch.
>
> Most notably, I'm not sure I see how your patch answers the original
> use case. The form data structure that is returned by the parser
> appears to contain a top-level dictionary containing the form
> instances. The form structure itself is irrelevant to reposting.
>
> However, thats not to say that keeping the form data is irrelevant.
> For example, consider the case where a page has multiple forms, or
> multiple submit buttons on a single form. If we're going to introduce
> a utility like this, then it should be able to behave at least
> partially like a browser - that is, I should be able to get the post
> data that is needed to respond to a specific button press:
>
> response = self.client.get('/path/to/page')
> # Get a copy of a data dictionary that contains the form data
> # that would be submitted if I pressed the submit button labeled 'button 3'
> data = response.form_data('button 3')
> data['some-field'] = 'new value'
> response = self.client.post('/path/to/page', data)
>
> We also need to be careful of feature creep - this sort of testing is
> exactly what Twill does, and we don't want to duplicate the efforts of
> that project (or any other automated Python client test framework for
> that matter).
>
That seems reasonable. I'll work on it and let you know when I have an
official patch ready.
--~--~-~--~~~---~--~~
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: Obtaining group members?
On Wed, Aug 26, 2009 at 10:36 AM, Francis Reyes wrote: > > Hi all > > I'm doing some custom permissions in modelAdmin and I need to obtain a > list of members from a the group . How can this be done? > > Thanks > > FR Please ask questions about using Django on the django-users mailing list. This list is for discussion about the development of Django itself. Thanks, Ian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Obtaining group members?
Hi all I'm doing some custom permissions in modelAdmin and I need to obtain a list of members from a the group . How can this be done? Thanks FR --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
