Re: Feature proposal: Test client form value extraction
On Wed, Aug 26, 2009 at 1:34 PM, Joshua Russo wrote:
> 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.
>
Let me know how this looks.
http://dpaste.com/hold/86057/
The only question I have is when I encounter a Form that doesn't have a name
or an id, should the index be a real number or should I convert it into a
string for consistency?
--~--~-~--~~~---~--~~
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 Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo wrote:
> On Wed, Aug 26, 2009 at 1:34 PM, Joshua Russo wrote:
>
>> 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.
>>
>
> Let me know how this looks.
>
> http://dpaste.com/hold/86057/
>
> The only question I have is when I encounter a Form that doesn't have a
> name or an id, should the index be a real number or should I convert it into
> a string for consistency?
>
Ok, so I found that the way I was 'casting' the response object didn't work.
Is there no way to cast an instance of a base class to a child class in
Python?
What I did was to create a class method on my child class that takes the
current response instance and creates a copy of it using my new response
object.
http://dpaste.com/hold/86193/
Does this look appropriate, or is there a better way to do this?
--~--~-~--~~~---~--~~
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
Hi, On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote: > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo wrote: > Ok, so I found that the way I was 'casting' the response object didn't work. > Is > there no way to cast an instance of a base class to a child class in Python? > > What I did was to create a class method on my child class that takes the > current response instance and creates a copy of it using my new response > object. > > http://dpaste.com/hold/86193/ > > Does this look appropriate, or is there a better way to do this? This should work: response.__class__ = TestHttpResponse -Forest -- Forest Bond http://www.alittletooquiet.net http://www.pytagsfs.org signature.asc Description: Digital signature
Re: App Engine support
Hey Waldemar and everyone else, termie here, I'm an App Engine developer and worked on the Django Helper library. This is something I'm deeply interested in (and many other app engine folk agree) and I'd like to work together. My initial goals are to get some concrete experiments up so that the people on this thread have something to point at for their arguments. I'm more of a git person and am used to the github workflow, but I'm not against checking out and trying to collaborate on your bitbucket project. --andy On Sat, Aug 15, 2009 at 2:42 AM, Waldemar Kornewald wrote: > > Hi Malcolm, > first of all, we'll soon start with a few experiments and since you > wanted to play around with some code, too, could you please tell us > your bitbucket username, so we can give you write access to the > repository? > > On Aug 11, 4:07 am, Malcolm Tredinnick > wrote: > > Things like a ListField aren't required. They could easily enough be > > done as a standard custom field, but support for every field that's > > possible in a particular database backend isn't our goal at the moment > > and we don't add stuff to Django for that reason. Django runs on > > app-engine would mean that existing applications run with the existing > > field types. Not that every possible app-engine storage structure is > > emulated in Django. > > ListField is a critical data type in non-relational DBs. There needs > to be a standard that works across all non-relational backends and > that makes it possible to switch back to an SQL-backed Django. How do > you want to solve that without integrating ListField into Django? > > > Batch delete() is already pretty much what happens. Batch updates > > already exist and batch saving is an often enough requested feature that > > it's likely to happen in the near future (I can imagine what an API for > > that might look like, for example). > > Unless I've misunderstood something, there's a problem with the > current batch-delete/update operations: You can't pass existing model > instances, but only PKs. In the worst case, all rows have to be re- > fetched from the DB and the models must be re-instantiated - just to > send signals. This could be a costly operation on non-SQL DBs, so if > one already has a list of instances he wants to delete they should be > reused. > > Bye, > Waldemar Kornewald > > > --~--~-~--~~~---~--~~ 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: App Engine support
Hi Andy, On Aug 27, 10:25 pm, Andy Smith wrote: > Hey Waldemar and everyone else, termie here, I'm an App Engine developer and > worked on the Django Helper library. > This is something I'm deeply interested in (and many other app engine folk > agree) and I'd like to work together. Fantastic! Welcome on board! I'm really happy that I bugged Guido about this topic *again*. :) > My initial goals are to get some concrete experiments up so that the people > on this thread have something to point at for their arguments. Once you feel comfortable enough with the source please tell us what you'll be working on, so we don't step on each other's toes. Here's the little summary in case Guido didn't forward that part of the discussion: The Django ORM work for supporting non-relational DB backends and possibly other Django-internal changes are in: http://bitbucket.org/gumptioncom/django-non-relational/ Just take a look at the few latest commits by Thomas Wanschik and me. I've collected all sql.Query functions that are used by QuerySet. See db.models.nonrelational.query.MinQuery. Next week we should be able to spend our 20% time slow on further work. The last two weeks have been too busy. The DB backend itself and other non-internal stuff will be kept as a separate project (until the Django team decides to integrate it - hopefully ;): http://bitbucket.org/gumptioncom/django-db-app-engine/ We also work on individual tickets and send patches (without committing them into the repositories). The email backend support is being worked on here (by Andi Albrecht): http://code.djangoproject.com/ticket/10355 We've also started documenting the required changes at a general non-sql level here: http://code.djangoproject.com/wiki/NonSqlBackends There's also a wiki page specifically for App Engine here: http://code.djangoproject.com/wiki/AppEngine Note: the section about key name/id handling has to be reworked a little bit (I didn't have all the necessary information when I initially wrote that section). > I'm more of a git person and am used to the github workflow, but I'm not > against checking out and trying to collaborate on your bitbucket project. Great. Please tell us your bitbucket username, so we can give you write access. The active contributors currently are: * Andi Albrecht (working on email backend support) * Thomas Wanschik (my colleague) * Waldemar Kornewald (that's me ;) Since we're all busy guys who can't work full-time on this project we could really need more contributors. It would be great to have more Google developers on board. ;) We also have a few other potential contributors on our list, but right now they're too busy or not ready for contributing, yet: * Thomas Bohmbach (from Giftag) * Curtis Thompson (from Giftag) * Joe Tyson (maybe you know him? :) * Malcolm Tredinnick (core Django developer) A few others have shouted, but I got no further reaction, so I don't mention them here (please correct me and say something if I mistakenly forgot you). Bye, Waldemar Kornewald --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
contrib.admindocs need some love.
Hey guys. I started writing some docs for another developer today and hit a few issues with admindocs that I plan on sprinting on for DjangoCon. I'm hoping anyone else with complaints / ideas will voice up, though my main impetus for the post is to announce that I'm going to do it so I can't back out. ;) Things I plan to address: 1. No tests. 2. No docs. 3. You can't seem to cross-link to views without the link being app.package.func . I'd like to see it at least configurable. 4. ManyToManyFields don't show up. There's not a ton there, but worth sprinting on, imo. Any other ideas or changes you'd like to see in admindocs that I might be able to work on? Shout them out. -justin signature.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Feature proposal: Test client form value extraction
On Thu, Aug 27, 2009 at 6:22 PM, Forest Bond wrote: > Hi, > > On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote: > > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo > wrote: > > Ok, so I found that the way I was 'casting' the response object didn't > work. Is > > there no way to cast an instance of a base class to a child class in > Python? > > > > What I did was to create a class method on my child class that takes the > > current response instance and creates a copy of it using my new response > > object. > > > > http://dpaste.com/hold/86193/ > > > > Does this look appropriate, or is there a better way to do this? > > This should work: > > response.__class__ = TestHttpResponse > Nope, it resets the status_code. That's what I tried at first. --~--~-~--~~~---~--~~ 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: contrib.admindocs need some love.
On Thu, Aug 27, 2009 at 4:03 PM, Justin Lilly wrote: > Hey guys. > > I started writing some docs for another developer today and hit a few > issues with admindocs that I plan on sprinting on for DjangoCon. I'm > hoping anyone else with complaints / ideas will voice up, though my main > impetus for the post is to announce that I'm going to do it so I > can't back out. ;) > > Things I plan to address: > > 1. No tests. > 2. No docs. > 3. You can't seem to cross-link to views without the link being > app.package.func . I'd like to see it at least configurable. I've actually got a patch that fixes this on my github django repo in the "admindocs" branch. > 4. ManyToManyFields don't show up. > I don't see this problem, for example User/Group show the relationship in both directions correctly, since you clearly don't see it there's probably some more debugging work needed here to figure it all out. > There's not a ton there, but worth sprinting on, imo. Any other ideas or > changes you'd like to see in admindocs that I might be able to work on? > Shout them out. > > -justin > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFKluajbdUY9pLj0/0RA97fAKCKqGSYv9tQacnnlGevWlTxVxly3QCdHZ4H > amfr89aN68C3xEvqCi1Cy/A= > =xrrK > -END PGP SIGNATURE- > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me --~--~-~--~~~---~--~~ 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
Hi, On Thu, Aug 27, 2009 at 07:42:24PM -0100, Joshua Russo wrote: > On Thu, Aug 27, 2009 at 6:22 PM, Forest Bond > wrote: > > Hi, > > On Thu, Aug 27, 2009 at 03:28:03PM -0100, Joshua Russo wrote: > > On Thu, Aug 27, 2009 at 11:54 AM, Joshua Russo > wrote: > > Ok, so I found that the way I was 'casting' the response object didn't > work. Is > > there no way to cast an instance of a base class to a child class in > Python? > > > > What I did was to create a class method on my child class that takes the > > current response instance and creates a copy of it using my new response > > object. > > > > http://dpaste.com/hold/86193/ > > > > Does this look appropriate, or is there a better way to do this? > > This should work: > > response.__class__ = TestHttpResponse > > > Nope, it resets the status_code. That's what I tried at first. Okay, you'd have to copy the class attributes, too. Or, you could just define a sub-class on-the-fly: class _TestHttpResponse(TestHttpResponse, response.__class__): pass response.__class__ = _TestHttpResponse I haven't tested this. -Forest -- Forest Bond http://www.alittletooquiet.net http://www.pytagsfs.org signature.asc Description: Digital signature
Ticket #7150 - view pemission in admin
I'm writing to see if I can get this ticket re-opened and added to a branch of django. I need to create an application level administrator who has read only access to other applications in the same project. I was able to follow most of the patches in this ticket and get everything working. It took lots of hours of work and I would like to add my give my changes back, but since this similar ticket is closed it doesn't look like the changes would be accepted. View permissions have made administration really nice now because with a few clicks I can let users browse data they need in other applications, without worrying about them changing everything. I saw this comment from one of the developers in the ticket... As such, there are no plans to add this feature; consider wiring up some generic views and applying permission-based decorators if you truly have a need for "administrators" who don't administer anything. As I added to the ticket I needed to be able to have an administrator who can modify some things but not everything. So they could look at a purchase order and jump over to the products without having the ability to modify products. It was also helpful for creating a group of moderators who can delete comments without being able to change what people have said. If it's a matter of work / responsibility I would be willing to take ownership of the ticket and implement the changes. The ticket said to discuss it on this list so here I am. Why not add view permission to default admin? --~--~-~--~~~---~--~~ 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: App Engine support
On Aug 27, 11:54 pm, Waldemar Kornewald wrote: > We also have a few other potential contributors on our list, but right > now they're too busy or not ready for contributing, yet: > * Thomas Bohmbach (from Giftag) > * Curtis Thompson (from Giftag) > * Joe Tyson (maybe you know him? :) > * Malcolm Tredinnick (core Django developer) > > A few others have shouted, but I got no further reaction, so I don't > mention them here (please correct me and say something if I mistakenly > forgot you). I knew I forgot someone right after having hit "Send". Sorry, was focusing too much on App Engine. :( Mitch Garnaat (creator of boto) wants to help with the non-relational backends refactoring and implement SimpleDB support. I haven't seen any code from him, yet, but he added some info to the documentation. His view on SimpleDB is really important for getting the non- relational code generic enough. I hope we could get more input from other DB users (e.g., CouchDB, MongoDB, Hadoop, ...). Bye, Waldemar --~--~-~--~~~---~--~~ 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: App Engine support
On Fri, Aug 28, 2009 at 5:54 AM, Waldemar Kornewald wrote: > > The active contributors currently are: > * Andi Albrecht (working on email backend support) > * Thomas Wanschik (my colleague) > * Waldemar Kornewald (that's me ;) > > Since we're all busy guys who can't work full-time on this project we > could really need more contributors. It would be great to have more > Google developers on board. ;) ... > A few others have shouted, but I got no further reaction, so I don't > mention them here (please correct me and say something if I mistakenly > forgot you). To the extent that I'm in a position to provide design guidance and feedback from the perspective of the Django Core, put me on this list too. Time permitting, I might be able to contribute some code, too. 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: App Engine support
On Fri, Aug 28, 2009 at 6:01 AM, Waldemar Kornewald wrote: > > On Aug 27, 11:54 pm, Waldemar Kornewald wrote: >> We also have a few other potential contributors on our list, but right >> now they're too busy or not ready for contributing, yet: >> * Thomas Bohmbach (from Giftag) >> * Curtis Thompson (from Giftag) >> * Joe Tyson (maybe you know him? :) >> * Malcolm Tredinnick (core Django developer) >> >> A few others have shouted, but I got no further reaction, so I don't >> mention them here (please correct me and say something if I mistakenly >> forgot you). > > I knew I forgot someone right after having hit "Send". Sorry, was > focusing too much on App Engine. :( > > Mitch Garnaat (creator of boto) wants to help with the non-relational > backends refactoring and implement SimpleDB support. I haven't seen > any code from him, yet, but he added some info to the documentation. > His view on SimpleDB is really important for getting the non- > relational code generic enough. I hope we could get more input from > other DB users (e.g., CouchDB, MongoDB, Hadoop, ...). While I encourage you to try to find common ground between these various data stores, don't get too hung up on trying to satisfy every possible non-relational backend at the same time. A single working implementation is better than a dozen partly working ones :-) As a side note - is there anyone out of this group of AppEngine aficionados that will be attending DjangoCon? It would be good if we can use the chance for face time to sort out any big-picture issues. 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 -~--~~~~--~~--~--~---
