Re: FormWizard and __call__
On Sun, Apr 13, 2008 at 6:13 PM, Honza Král <[EMAIL PROTECTED]> wrote: > > I was going to say "Put the cache into self.foo", but now I'm just > > realizing that there is just one FormWizard instantiated in urls.py, > > so different people could be using the same FormWizard instance. > > there is no easy solution for this one - you could create your own > instance evrytime in a view, that would get rid of the problem with > more users on one instance, but what about multi-process (let alone > multi box) deployment, where there is no guarantee that request from > the same user will end up in the same process. Yeah, I definitely see that. I guess it's a fairly typical problem in Django/webdevelopment land. I always tend to forget about it when developing with the dev server. > > I was hoping (assuming some kind of cache is available, even if it's > > sessions) that the first time a form is instantiated, we cache the > > names and values of the POST data that the form uses. Next time > > get_form() is called, we check if those same values are still there. > > you could do that, but the it would just be easier to store all the > values in session. Why not, but its not what the wizard class does > (although it might be very easy to enable multiple storage options via > hooks) Maybe I'll look into that. > the easiest solution to your issues with the wizard class would be to > modify it to allow storing of the data in session, so that you could > move all this there. I am still -1 on storing the data on the server, > but if a clean implementation of pluggable storage (get_data(request): > return request.POST ??? ) is in place, I will have no objections > against the possibility. I'll see what I can do. Here's a question though: Do you think the documentation for FormWizard should be changed, especially around process_step, and mentions of form_list? This is the part that ended up really confusing me: "This method should not modify any of that data. Rather, it might want to set self.extra_context or dynamically alter self.form_list, based on previously submitted forms." From my experience here, it seems one really shouldn't be dynamically altering form_list, unless you want that alteration to globally affect all users. Because this chunk of text is listed in the process_step() documentation, I got the impression that form_list was much more fine-grained than that. Jay P. --~--~-~--~~~---~--~~ 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: FormWizard and __call__
On 4/11/08, Honza Král <[EMAIL PROTECTED]> wrote: > On Fri, Apr 11, 2008 at 4:15 PM, Jay Parlar <[EMAIL PROTECTED]> wrote: > > Currently when we call get_form(i, request.POST) in __call__, we just > > arbitrarily recreate the Form instance. What if on the first time we > > create that instance, we hash and cache the components of request.POST > > that are associated with that form? We can tie parts of request.POST > > to a particular step, because the step is prepended to each key in > > request.POST. Then when get_form() gets called again, we can just > > check whether the POST data has changed. If it hasn't, we can return > > the same Form instance. > > > yes, but the POST can contain any data, only the form can know which > are interesting for us. The problem also is how do you want to cache > this between requests? Some sites do not have caching enabled, so > unless you want to store it in sessions (so there would be absolutely > no point in storing it in hidden fields as well) you have no place to > put that. I was going to say "Put the cache into self.foo", but now I'm just realizing that there is just one FormWizard instantiated in urls.py, so different people could be using the same FormWizard instance. Hmmm Is that right? Because that really screws up my perception now of what's going on. (For example, is it safe to put dynamic data into self.form_list, because multiple people could be getting their form_list affected by that. Sometimes working in just the dev server makes me forget to think about issues like this). I was hoping (assuming some kind of cache is available, even if it's sessions) that the first time a form is instantiated, we cache the names and values of the POST data that the form uses. Next time get_form() is called, we check if those same values are still there. We'd have to be careful though: If a user is on step Y, and a change is noticed when calling get_form() on a step X (where X < Y), we'd have to invalidate the caches for all steps after X, and reinstantiate those forms when get_form() is called for them. > the hash is computed from cleaned data, from data that represent the > form fields, without prefixes etc, unlike the data contained in POST, > that doesn't know which form they belong to etc. That's why I was thinking of caching the names/values of the required data in POST, for each step. > If you feel that I didn;t understand your proposal you are probably > right, a code snippet would definitely help ;) I'll wait for your answers to what I've thrown up above, and then see what I can do. Probably no time this weekend to try though :) BTW: Web programming is not my forte. I try to get into Django whenever I can, but I'm mostly a server-side and embedded guy, so please forgive me if I get some concepts regarding requests wrong. Thanks, Jay P. --~--~-~--~~~---~--~~ 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: FormWizard and __call__
On Fri, Apr 11, 2008 at 8:03 AM, Honza Král <[EMAIL PROTECTED]> wrote: > you could perhaps postpone the validation of data till the end of the > wizard, so only run this once, but that could cause problems for > example if the user chose to override process_step and do something > based on the unsaved forms, for example generate third step > dynamically based on data from the second. If we didn't instantiate > the form and check the hash, we wouldn't be able to guarantee > correctness of the data in previous steps. Overriding process_step is how I originally ran into this. I wanted to dynamically create new Form classes (and add them to form_list), based on the results of the first submitted forms. The problem was this ended up recreating the new Form classes over and over in process_step, and it kept appending them to form_list. > If you have any proposals on how to go around this, I will be happy to help > out. Currently when we call get_form(i, request.POST) in __call__, we just arbitrarily recreate the Form instance. What if on the first time we create that instance, we hash and cache the components of request.POST that are associated with that form? We can tie parts of request.POST to a particular step, because the step is prepended to each key in request.POST. Then when get_form() gets called again, we can just check whether the POST data has changed. If it hasn't, we can return the same Form instance. So I'm essentially wondering whether we can do the reverse of what's being done now. You currently instantiate the form, and do a security_hash on it. I'd like to do a hash on the POST data, and then instantiate if necessary (i.e. if we haven't already instantiated for this hash). Or am I missing something here? Thanks, Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
FormWizard and __call__
I originally posted this in -users, but since it deals with internals,
maybe it's more appropriate for -dev.
I'm looking at the FormWizard code, and in __call__, we have the following:
for i in range(current_step):
form = self.get_form(i, request.POST)
if request.POST.get("hash_%d" % i, '') != self.security_hash(request, form):
return self.render_hash_failure(request, i)
self.process_step(request, form, i)
My concern is that self.get_form() gets called everytime through. This
means that our form instances are being recreated/instantisated over
and over again.
I understand wanting to handle the case where some data has changed,
but shouldn't there be some sort of cache so we don't need to keep
recreating the instances?
Jay P.
--~--~-~--~~~---~--~~
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: How to stop spam on our groups
On 1/12/08, Ned Batchelder <[EMAIL PROTECTED]> wrote: > > The moderation could be done by member(s) whose time wouldn't be spent > enhancing django. I used to volunteer on python.org to maintain the > Python Jobs Board, because I wanted to help out, but I wasn't able to > contribute in ways that other people already were (sysadmin stuff). > Perhaps if there were two or three people who cared about Django but > were not otherwise engaged in the improvement of Django, they could help > by taking the moderation and/or cleanup task off the shoulders of the > maintainers. > > The problem with this scheme is finding people who will do it reliably, > and won't suddenly drop off without warning. Any estimates as to how much time would be required? I've been following -dev and -users since the summer of 2006, and would be happy to help. Haven't really posted in 6 months or so, as I'm not currently working on any Django projects, but I do read the lists every day. Jay P. --~--~-~--~~~---~--~~ 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: __slot__ like behaviour for Model classes?
On 9/1/07, jorjun <[EMAIL PROTECTED]> wrote: > But I disagree with __slots__ being justified purely for optimization > purposes. Disagree all you want, but this is what Guido Van Rossum, creator of Python and BDFL, had to say about it: "__slots__ is a terrible hack with nasty, hard-to-fathom side effects that should only be used by programmers at grandmaster and wizard levels. Unfortunately it has gained an enormous undeserved popularity amongst the novices and apprentices, who should know better than to use this magic incantation casually." Jay P. --~--~-~--~~~---~--~~ 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: __slot__ like behaviour for Model classes?
On 8/31/07, jorjun <[EMAIL PROTECTED]> wrote:
>
> Glad though I am that Python has dynamic class attributes, when it
> comes to Django Models, some more discipline could be useful,
> especially when a product is in maintenance phase, IMO.
>
> I recently added the code below to my model definition and it saved me
> a bunch of time after some model evolution, by making sure that old
> attributes were not still being referred to in templates.
>
> Wondering whether code like this could be implemented as decorator or
> activated as an optional meta attribute to the Django Model class if
> found generally useful, ideally it should be possible to detail any
> exceptions for those rare cases when the usual Python dynamic run-time
> attribute get/set behaviour is still required?
> It would be good to hear informed comments, in case I am completely
> wrong headed about this...
>
> def __setattr__(self, name, value):
> if name.startswith("_") or name.endswith("id") or \
>name in self.__slots__:
> self.__dict__[name] = value
> else:
> raise AttributeError, "Illegal set attempt: %s = %s" %
> (name, value)
>
> def __getattr__(self, name):
> if name.startswith("_") or name.endswith("id") or \
>name in self.__slots__:
> if self.__dict__.has_key(name):
> return self.__dict__[name]
> else:
> return getattr(super(Listing, self), name)
> else:
> raise AttributeError, "Illegal get attempt: %s" %name
>
Just so you know, the intended behaviour of __slots__ is *not* to
restrict dynamic behaviours. It is simply an optimization technique.
It is generally considered "wrong" to use __slots__ for restrictive
purposes, as it goes against the grain of Python.
And I'm not sure if you've actually run that code, or if I'm missing
something, but if a class does have __slots__ defined on it, then, by
definition, the class will *not* have a __dict__ attribute.
Jay P.
--~--~-~--~~~---~--~~
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: Amazon S3 Integration
On 8/8/07, John-Scott <[EMAIL PROTECTED]> wrote: > > Hello all, > > I'm trying to integrate S3 support into my Django app using > http://code.djangoproject.com/wiki/AmazonSimpleStorageService for > now. > > I would like to improve the code so that it might be officially > integrated into Django at some point. The first obvious question: Is > this a feature that others would like to see, enough so to warrant > having this feature 'baked-in'? Or should I just keep my hacks to > myself? > > I want to rewrite the code so that it doesn't subclass FileField, as > it currently does, but instead adds or alters the parameters to > FileField which can then be inherited by ImageField. Currently, the > S3FileField subclasses FileField and then has to duplicate some of the > functionality of ImageField, so it's not very DRY. The options I want > to add to FileField would determine whether or not the file should be > stored on the filesystem (the default) or to S3, plus additional > options specific to S3 storage (bucket and key values, etc.). Obviousy > this would involve tinkering with Django's models code directly so I > want to solicit feedback from the Python/Django pros before I go down > this path. My guess would be that the core team would never accept changes to the base fields which add provider (ie. Amazon) specific features. Things like that are better left in contrib. I would personally rather have an S3FileField. Of course, if you changed FileFIeld such that you could use it with *any* S3-style provider, by passing it the right data (maybe some callbacks, or something), that'd be cool. Jay P. --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > I could use a file as cache, yes, but what you're dsecribing wouldn't > really work well in production environments. To my knowledge, Django > reloads itself in its entirety if any loaded modules are changed, not > just a single file. Sure, these things will change rarely enough that > it might be tolerable, but the goal of the project was to avoid > restarting the server, and this method would do exactly that. > Additionally, the autoreload option isn't always available depending > on your setup. > > That said, mod_python does provide its own autoreloading import > system[1], which could probably be used for this, I suppose. By doing > it that way, it would only reload the one file, which should happen > pretty quickly. It's definitely an approach I hadn't considered, so > I'll add it to the list of options. > But then you need to figure out the autoreload options for any particular web server that might be used. The dev server does autoreloading, but most of the others don't by default. I'd go with the database option. These options aren't going to change too often, so the db's cache (if any) should return the result quick enough, and you know that in *all* circumstances, a db will be present. Of course, that's just my opinion for the colour of this particular bikeshed. Jay P. --~--~-~--~~~---~--~~ 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-values -> django-policy?
On 5/29/07, James Bennett <[EMAIL PROTECTED]> wrote: > > In all seriousness: django.contrib.bikeshed. > That actually made me laugh, but I think you have a valid point. This is definitely a bikeshed topic, but maybe that name can actually work. django-values provides storage and easy access to values that might need to change, a bikeshed provides storage and easy access to bikes. Plus, naming it that keeps the sense of humour that is evident around the Django community. People interested in working with any of the contrib apps will have to read the docs anyway, and we have a page that gives a short summary of each contrib app (http://www.djangoproject.com/documentation/add_ons/), so people interested in using contrib apps will know what it does anyway. +1 for django.contrib.bikeshed Jay P. --~--~-~--~~~---~--~~ 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: GSoC status?
On 4/28/07, David Larlet <[EMAIL PROTECTED]> wrote: > I just hope those ones will be successful! Maybe we can learn from the > past and improve students/dev communication in order to help them a > bit more if they need it? I think for the most part, in terms of the scope of GSoC, the previous ones were successful. It seemed like most of the hard work was done, for each of the branches. (At least, auth and rlp seemed to do quite well). Problem was there wasn't enough demand/interest in the community to get them fully integrated, no one was stepping up to take over. There were always people (myself included) that wanted to use the various branches, but no one was willing to put the time in to make them trunk ready. The one problem with GSoC is that while students may have lots of time in the summer, that time tends to go towards zero once September hits :) I guess it all just depends on your measure of "success". Jay P. --~--~-~--~~~---~--~~ 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: Add note about removing egg to install docs?
On 4/11/07, Simon G. <[EMAIL PROTECTED]> wrote: > > Hi Jay, > > Someone reported that issue a few weeks ago, and I added a quick patch > for this here: > > http://code.djangoproject.com/ticket/3830 > > It can probably be enhanced beyond that though. D'oh, I should have checked Trac first :) I wonder though, is it only an OS X problem? I can't verify, because all my machines are OS X, but I'd imagine that the same problem would be present on Windows, and any Linux machine where the user did a manual install (as opposed to 'apt' or 'emerge' or something similar). Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Add note about removing egg to install docs?
Recently in [1], someone ran into a problem after installing 0.96. Namely, the 0.95 egg was still on the system, and overriding the 0.96 install. Could we maybe get a note in the install document to help people out with this? I forsee lots of people asking about this in the near future, as more people move their installs to 0.96. [1] : http://groups.google.com/group/django-users/browse_thread/thread/4340284e3b4705ba Jay P. --~--~-~--~~~---~--~~ 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: Backwards incompatible changes
On 4/7/07, Noah <[EMAIL PROTECTED]> wrote: > > I'm worried about a trend I've seen before in other frameworks etc. > They start off easier to use and over time get more and more > generalized and then become so general and so academically correct > that there is no point in using them because they're just as general > as if you had to write all your own code to start with. I'm not saying > that's happened I'm just trying to raise my concern. I think one thing that Django has on its side is the fact that the framework is constantly being used for real-world, useful things (Washington Post, all the Lawrence stuff, etc.). The development of Django is not an academic exercise, it's being done to facilitate solutions to real-world problems. Jay P. --~--~-~--~~~---~--~~ 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: Google Summer of Code 2007
On 2/26/07, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > I for one am very keen to see RLP branch integrated and I tested it > months ago to my satisfaction. > > [1] > http://groups.google.com/group/django-developers/browse_thread/thread/f124083c6194dccc/ I too would be very excited to see it integrated. I've got a production site running with it right now, and it'd be nice to be able to run that from an official release. It was started last year as a SoC project by Chris Long. If he doesn't want to come back to finish it off, I could probably be persuaded to take it over as a SoC project, being the PhD student that I am. Jay P. --~--~-~--~~~---~--~~ 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 ORM bug when your app has a model named "ContentType"?
On 1/31/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > > > Django has a builtin type called "ContentType", > > http://code.djangoproject.com/browser/django/trunk/django/contrib/con... > > > > I'd just rename yours to something else and be done with it. > > As a workaround, sure. I've already worked around the issue. > > But I don't think Django would want this type of restriction. I've > tried to track how this might get in the SQL myself but it's beyond > me. I'm just offering to help assist or share my model offline if > needed. ContentType is used all over the place, if I remember correctly (been awhile since I looked). Marc is right, it's a reserved name. It's a bit like saying you want to use the word "if" as a variable name. It's reserved, it has it's place, it got there before you did :) Jay P. --~--~-~--~~~---~--~~ 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 ORM bug when your app has a model named "ContentType"?
On 1/30/07, Rob Hudson <[EMAIL PROTECTED]> wrote: > > I'm getting a weird bug here and this is what I've deduced... > > I've got a "Page" model and a "Content" model. Content has a FK to > Page. I also have a "ContentType" model and Content has a FK to > ContentType. This is where I tell it if the content is text or other > media content. Django has a builtin type called "ContentType", http://code.djangoproject.com/browser/django/trunk/django/contrib/contenttypes/models.py I'd just rename yours to something else and be done with it. Jay P. --~--~-~--~~~---~--~~ 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: So, Guido *is* using Django
On 12/1/06, James <[EMAIL PROTECTED]> wrote: > > I'd read somewhere that he expresses a preference for Django, but seems > he's using it for real work: > > "Guido van Rossum, author of the Python programming language, has begun > showing off his first project since joining Google last year ... The > application is built on top of Python open source libraries such as the > Django framework, smtpd.py mail service, and the wsgiref Web server > software." > > http://developers.slashdot.org/developers/06/12/01/1952205.shtml I seem to remember an interview with him saying that he was using the Django template language, but that was just about it. Jay P. --~--~-~--~~~---~--~~ 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: Branch Merges?
On 11/6/06, David Blewett <[EMAIL PROTECTED]> wrote: > > I would like to suggest that the branches that are felt to be complete > sans testing be merged into a single branch. I am anxiously awaiting > several different branch merges to core but do not have time to check > each individual one out to test them. Maybe it's time to begin a larger > effort, similar to magic-removal, at merging all these branches? This is a constant complaint we're seeing now. The problem is, not enough people are actually jumping in and testing out the branches. The core devs tell people all the time that it's generally safe to run Django off the trunk, but if a bunch of untested branches are merged in, well, welcome to disaster time. I wasn't around during the magic removal merging, but I'd assume that a lot of people were involved, testing out changes. People aren't jumping up to volunteer here. Jay P. --~--~-~--~~~---~--~~ 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: What's going on with all these branches?
I've reported at least a few times on django-dev and django-users that I've had a lot of success with row-level-permissions. I found some bugs early on, but Chris Long squashed them all for me. I'm currently running a production site with that branch. My requirements of it are pretty minimal, but it's working so far for what I'm doing. Jay P. --~--~-~--~~~---~--~~ 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: Login required across entire project Middleware
On 10/27/06, Jared Kuolt <[EMAIL PROTECTED]> wrote: > > I'd like to add a Middleware class that I wrote to the Wiki, but I keep > getting rejected by askimet. > > The class requires an authenticated user for every view. This is > beneficial for any closed project. Does anyone suppose something like > this is beneficial enough to make it into the Django source? > > I don't want to post the code here unless okayed by a developer. > That seems useful enough that you should probably just post it. Or make a Wiki page about it on djangoproject.com, and post the URL. I know I'd certainly have use cases for it, even if it doesn't make it into the Django core. Jay P. --~--~-~--~~~---~--~~ 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: Call for testing: New setup.py
OS X 10.3.9 with Python 2.4.3 seems fine. Jay P. --~--~-~--~~~---~--~~ 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: Call for testing: New setup.py
On 10/16/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > But I have only tested this on Linux, so I'd appreciate it if folks > could test out the command "python setup.py install" on various > different platforms. Just grab the SVN version of Django and try > installing it using "python setup.py install". Python 2.5 with OS X 10.4.8 (Intel) seems fine. I'll try Python 2.4 with OS X 10.3.9 when I get home. Jay P. --~--~-~--~~~---~--~~ 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: Merging branches. was:Re: bump: give Gabor (or somebody else) a unicode branch in svn
On 10/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Actually I have a need for both row-level-permissions (at least I > hope the model fits my needs) AND multi-db branch so would be thrilled > to be able to easily get them both. > Well, all I can say about that is try testing with them (I guess you'll have to test them individually, unless you want to merge them yourself), and let us know how it goes. I was able to uncover at least a few bugs in the row-level-permissions stuff, which Chris Long quickly fixed. At this point though, there don't seem to be any bugs in it within my use cases. Jay P. --~--~-~--~~~---~--~~ 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: bump: give Gabor (or somebody else) a unicode branch in svn
On 10/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Hey there, > > I'm very interested in getting this done, but we've got quite a few > branches open at the moment. I think we should focus on merging at > least one of these branches before opening another one, for the sake > of everybody's sanity. > I know it's off-topic, but do you have any thoughts as to which branch? I've been having success with the row-level-permissions branch, within my own limited use cases. And Chris Long was always very responsive to correcting bugs I found in my testing. It looks like it's also been the most active branch, at least recently. Although I *seem* to remember Jason Pellerin being pretty confident with the state of the multi-db branch, within his own use cases. Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
"Edit Row Level Permissions" showing up everywhere in Admin
(Chris), After a recent update of the row-level branch, every single instance of every model in the Admin is now getting the "Edit Row Level Permissions" button on the top right, even the models that don't have "row_level_permissions = True" in their Meta class. Jay P. --~--~-~--~~~---~--~~ 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: Further "little, easy improvements" ?
On 9/20/06, Nick <[EMAIL PROTECTED]> wrote: > > Jay Parlar wrote: > > > There's still the schema evolution, multi-db, multi-auth and > > search-api branches. I think it'd be great to get all of those into > > the Django core/contrib, but without more testing of them, it'll never > > happen. > > Good suggestions, although I was thinking of something littler and > easier :) Testing is easy, you don't even have to write one line of code :) Jay P. --~--~-~--~~~---~--~~ 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: Further "little, easy improvements" ?
On 9/18/06, Nick <[EMAIL PROTECTED]> wrote: > > Most, if not all, of the "little, easy improvements" listed on > www.djangoproject.com have now been made. I feel the urge on > contribute once more, so is there anything else little and easy that I > could do? > My suggestion would be to help do some testing on the various branches that are sitting in SVN. I've been trying to do some work with the row level permissions, and was able to find a few corner-case bugs. Chris has been very helpful in getting them fixed quickly. There's still the schema evolution, multi-db, multi-auth and search-api branches. I think it'd be great to get all of those into the Django core/contrib, but without more testing of them, it'll never happen. Just my two cents. Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RowLevelPermissions and show_all_rows
Having a problem right now when settings show_all_rows to False in a model with OneToOne. Basic model is this (same as my other posts on OneToOne and RLP): class UserProfile(models.Model): home_address = models.TextField(blank=True,null=True) user = models.OneToOneField(User) class Admin: show_all_rows = False grant_change_row_level_perm=True class Meta: row_level_permissions = True What I do right now is create a UserProfile instance with my superuser, for user X. I then give user X "Can change user profile" permissions on that instance. When I login to the Admin with user X, I can see the "User Profiles" option on the main Admin screen. When I click on it however, I get this: " Database error Something's wrong with your database installation. Make sure the appropriate database tables have been created, and make sure the database is readable by the appropriate user. " The URL for this request turns to: http://192.168.0.102:8000/admin/members/userprofile/?e=1 I've tried tracking the problem down myself, not a whole lot of luck though. If I remove the 'show_all_rows=False', then everything works fine and dandy. Any thoughts, Chris? (And I've tried dropping and recreating the auth_rowlevelpermission db table, to no avail). Jay P. --~--~-~--~~~---~--~~ 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: RowLevelPermissions and OneToOne problem
On 9/17/06, Chris Long <[EMAIL PROTECTED]> wrote: > > Hey, > > Latest release should fix both. The user_id problem is related to the > generic relations used in the POP branch, I've written up a ticket > #2749 about it, but it has been fixed in my branch. > > Let me know how it goes. Worked perfectly! I'll let you know if anything else comes up. Jay P. --~--~-~--~~~---~--~~ 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: RowLevelPermissions and OneToOne problem
The error seems to be related to this code in db/models/query.py:
for related in cls._meta.get_all_related_many_to_many_objects():
for offset in range(0, len(pk_list), GET_ITERATOR_CHUNK_SIZE):
cursor.execute("DELETE FROM %s WHERE %s IN (%s)" % \
(qn(related.field.m2m_db_table()),
qn(related.field.m2m_reverse_name()),
The .m2m_reverse_name() is returning 'user_id', because of the
UserProfile object related to person who's permission is being
deleted. Because the UserProfile is One-To-One though, 'user_id' is
returned, instead of 'id' like all the other related objects.
If I hardcode it to be 'id' instead of m2m_reverse_name(), then
everything works, but that's obviously not the right solution.
Jay p.
--~--~-~--~~~---~--~~
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: RowLevelPermissions and OneToOne problem
Oh, and interestingly, the row level permission I was trying to delete *does* in fact get deleted, despite my seeing this error. Jay P. --~--~-~--~~~---~--~~ 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: RowLevelPermissions and OneToOne problem
I'm going to keep lobbing them at you, until it all works :) I'm still trying to delete a row level permission, and I'm getting: Traceback (most recent call last): File "/Users/jayparlar/Library/Python2.4/site-packages/django/core/handlers/base.py" in get_response 74. response = callback(request, *callback_args, **callback_kwargs) File "/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/decorators.py" in _checklogin 55. return view_func(request, *args, **kwargs) File "/Users/jayparlar/Library/Python2.4/site-packages/django/views/decorators/cache.py" in _wrapped_view_func 39. response = view_func(request, *args, **kwargs) File "/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/row_level_permissions.py" in delete_row_level_permission 136. rlp.delete() File "/Users/jayparlar/Library/Python2.4/site-packages/django/db/models/base.py" in delete 280. delete_objects(seen_objs) File "/Users/jayparlar/Library/Python2.4/site-packages/django/db/models/query.py" in delete_objects 933. pk_list[offset:offset+GET_ITERATOR_CHUNK_SIZE]) File "/Users/jayparlar/Library/Python2.4/site-packages/django/db/backends/util.py" in execute 12. return self.cursor.execute(sql, params) File "/Users/jayparlar/Library/Python2.4/site-packages/django/db/backends/mysql/base.py" in execute 35. return self.cursor.execute(sql, params) File "/Users/jayparlar/Library/Python2.4/site-packages/MySQLdb/cursors.py" in execute 163. self.errorhandler(self, exc, value) File "/Users/jayparlar/Library/Python2.4/site-packages/MySQLdb/connections.py" in defaulterrorhandler 35. raise errorclass, errorvalue OperationalError at /admin/articles/article/1/row_level_permissions/delete/40/2/b740d56cf5040c879770e6ec263fc004477acd40/ (1054, "Unknown column 'user_id' in 'where clause'") What I did was add a "change permission" to an Article instance, then deleted it (which caused the error), where my Article model is: class Article(models.Model): title = models.CharField(maxlength=200, unique=True) slug = models.SlugField(prepopulate_from=['title']) body = models.TextField() class Admin: show_all_rows = False grant_change_row_level_perm = True grant_delete_row_level_perm = True class Meta: row_level_permissions = True --~--~-~--~~~---~--~~ 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: RowLevelPermissions and OneToOne problem
Another problem along the same vein just popped up.
I was trying to add a "change user profile" row level permission for a
user, and I got this:
Traceback (most recent call last):
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/core/handlers/base.py"
in get_response
74. response = callback(request, *callback_args, **callback_kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/decorators.py"
in _checklogin
55. return view_func(request, *args, **kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/views/decorators/cache.py"
in _wrapped_view_func
39. response = view_func(request, *args, **kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/row_level_permissions.py"
in add_row_level_permission
175. rlp_list = manip.save(new_data)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/row_level_perm_manipulator.py"
in save
80. all_data = {'owner_id':owner.id, 'model_ct_id':self.ct.id,
'model_id':self.obj_instance.id, 'permission_id':perm.id}
AttributeError at /admin/members/userprofile/5/row_level_permissions/add/
'UserProfile' object has no attribute 'id'
Using the cue from your earlier patch, this seems to fix it:
--- django/contrib/admin/row_level_perm_manipulator.py (revision 3753)
+++ django/contrib/admin/row_level_perm_manipulator.py (working copy)
@@ -77,7 +77,8 @@
#Check that the new row level perms are unique
field_name_list = ('owner_ct', 'owner_id', 'model_ct',
'model_id', 'permission'):~/src/svn/django_src jayparlar$
field_data = ct.idrc jayparlar$ vim django/contrib/admin/models.py
-all_data = {'owner_id':owner.id,
'model_ct_id':self.ct.id, 'model_id':self.obj_instance.id,
'permission_id':perm.id}anipulator.pyc
+model_id = self.obj_instance._get_pk_val()
+all_data = {'owner_id':owner.id,
'model_ct_id':self.ct.id, 'model_id':model_id,
'permission_id':perm.id}.py
manipulators.manipulator_validator_unique_together(field_name_list,
self.opts, self, field_data, all_data)
utils.pyc
rlp =
RowLevelPermission.objects.create_row_level_permission(self.obj_instance,
owner, perm, negative=new_data['negative'])
Jay P.
--~--~-~--~~~---~--~~
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: RowLevelPermissions SQL error
On 9/12/06, Chris Long <[EMAIL PROTECTED]> wrote: > > Latest changeset should fix it. > > Chris Worked like a charm! I've got pretty minimal needs right now, when it comes to the row-level permissions, but I'll keep working with it and let you know if anything else happens. My entire site right now is run by generic views, so all my needs come in at the Admin level. I have about 10 people who are allowed to log into the Admin, and I basically don't want them to edit each others' UserProfile and Articles. So far, it seems to be working ok. Jay P. --~--~-~--~~~---~--~~ 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: RowLevelPermissions and OneToOne problem
On 9/12/06, Chris Long <[EMAIL PROTECTED]> wrote: > > Nope, not a correct assumption. > > Fixed in the latest version, I did try it with the model you have given > and it does work, but the test was not as indepth (lack of time this > week). So please give it a try and see if it fixes this problem. Looks to be working now, thanks a lot. Jay P. --~--~-~--~~~---~--~~ 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: RowLevelPermissions SQL error
On 9/12/06, Chris Long <[EMAIL PROTECTED]> wrote: > > I'll take a look at it today. > > Chris > Thanks. Let me know if you need any more details on anything, I'll be around most of the day. Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RowLevelPermissions SQL error
More playing with the per-object branch, and just received this error:
Traceback (most recent call last):
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/core/handlers/base.py"
in get_response
74. response = callback(request, *callback_args, **callback_kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/decorators.py"
in _checklogin
55. return view_func(request, *args, **kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/views/decorators/cache.py"
in _wrapped_view_func
39. response = view_func(request, *args, **kwargs)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/main.py"
in change_list
775. cl = ChangeList(request, model)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/main.py"
in __init__
585. self.query_set = self.get_query_set()
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/admin/views/main.py"
in get_query_set
697. self.opts.get_change_permission()))
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/contrib/auth/models.py"
in get_model_list
88. id_list = [o['model_id'] for o in user_model_ids] +
[o['model_id'] for o in group_model_ids]
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/models/query.py"
in __iter__
103. return iter(self._get_data())
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/models/query.py"
in _get_data
430. self._result_cache = list(self.iterator())
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/models/query.py"
in iterator
528. cursor.execute("SELECT " + (self._distinct and "DISTINCT " or
"") + ",".join(select) + sql, params)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/backends/util.py"
in execute
12. return self.cursor.execute(sql, params)
File
"/Users/jayparlar/Library/Python2.4/site-packages/django/db/backends/mysql/base.py"
in execute
35. return self.cursor.execute(sql, params)
File "/Users/jayparlar/Library/Python2.4/site-packages/MySQLdb/cursors.py"
in execute
163. self.errorhandler(self, exc, value)
File "/Users/jayparlar/Library/Python2.4/site-packages/MySQLdb/connections.py"
in defaulterrorhandler
35. raise errorclass, errorvalue
ProgrammingError at /admin/members/role/
(1064, "You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near ') AND `auth_rowlevelpermission`.`owner_ct_id` = 2)' at line 1")
Here's the setup:
I have a model defined as follows:
class Role(models.Model):
position = models.IntegerField(choices=MEMBERSHIP_STATUS)
class Admin:
grant_change_row_level_perm=True
show_all_rows = False
class Meta:
row_level_permissions = True
I have a user "q2" with the general permissions "Can add role" and
"Can delete role".
I log into the Admin with "q2", and add a new row. Works fine. Go back
to the main admin page, and click on "Roles", and I get the error
above.
Jay P.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
RowLevelPermissions and OneToOne problem
I decided to try out the RowLevelPermissions branch today, and apply it to some code I haven't put into production yet. My model is essentially this: class UserProfile(models.Model): home_address = models.TextField(blank=True,null=True) user = models.OneToOneField(User) class Admin: grant_change_row_level_perm=True class Meta: row_level_permissions = True Because I'm using a OneToOneField, there's no 'id' field, instead, 'user_id' becomes the primary key. Because of this, the 'grant_change_row_level_perm' breaks the Admin. When I go to create a new UserProfile instance in the Admin, I get this: AttributeError at /admin/members/userprofile/add/ 'UserProfile' object has no attribute 'id' ... Exception Location: /Users/jayparlar/Library/Python2.4/site-packages/django/contrib/auth/models.py in create_row_level_permission, line 58 Is there a problem with my understanding of things here? Is there a reason that RowLevelPermissions shouldn't be allowed on models with a OneToOne? I can see the technical reason in the code, namely that the code assumes we have an 'id' field. But is that a correct assumption? Jay P. --~--~-~--~~~---~--~~ 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: App portability
On 9/7/06, Nate Straz <[EMAIL PROTECTED]> wrote: > Wow, I never knew about that syntax. I checked the Language Reference > all the way back to the 1.5 release and it is in every release. I'm > surprised I've never seen that syntax used before. > > Thank you for pointing that out. The reason you've never used it before (and couldn't find it) is because it's new in Python 2.5, which hasn't even hit its official release yet :) Jay P. --~--~-~--~~~---~--~~ 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: Test framework and dispatching benchmarks
On 8/29/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Personally, I find myself leaning towards option 3 - outside of testing, I > can't see any use case for a template-rendering signal, and I don't like > special cases. Instrumentation of the rendering system as part of the test > framework setup seems an appropriate solution. > My personal preference is for option 3. While testing is incredibly important, a site with decent traffic will spend 99% of its execution time, over its lifetime, responding to actual requests, as opposed to running tests. Some might call it premature optimization, but I'd prefer not to see something go in that will essentially result in wasted cycles 99% of the time. And remember that even for option 2, there's not just the cost of a boolean comparison. There's also the cost of a namespace lookup to get 'TESTING' from 'settings', unless you want to do a 'from settings import TESTING'. Jay P. --~--~-~--~~~---~--~~ 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: Convince us to continue using setuptools
On 8/2/06, Deryck Hodge <[EMAIL PROTECTED]> wrote: > > > Adrian Holovaty wrote: > > > > > > So, convince us to continue using setuptools. What incentive do we > > The easy packaging is a big plus, and I think, too, that "python > setup.py install" is becoming somewhat of the defacto python > installation standard. If it's just the network connection that's the > major issue, don't do ez_setup. Just require users have setuptools > installed. It's so common, I think, they'll have to install > setuptools eventually when dealing with Python. "python setup.py install" has been the defacto standard for years and years, it's a distutils feature. Jay P. --~--~-~--~~~---~--~~ 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: Convince us to continue using setuptools
On 8/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Here are a couple that I've been thinking about, both using setuptools > entry points. Hmm... I forgot about that. Jason's right, entry points do rule. At least from what I've seen of them in nose.py :) If there is an effort to move to entry points, then yeah, keep setuptools. Otherwise though... Jay P. --~--~-~--~~~---~--~~ 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: Convince us to continue using setuptools
I'm in general a big fan of setuptools. However, I don't really see a need for it in Django. I say dump it. Jay P. --~--~-~--~~~---~--~~ 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: 'filesize' patch for humanize
Oh jeez, I just noticed the 'filesizeformat' filter... Well, there's 5 minutes of my life I'll never get back :) Jay P. On 8/1/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > I just added a patch (http://code.djangoproject.com/ticket/2466) that > adds a 'filesize' filter, which returns filesizes (from get_XXX_size) > in a human friendly way. > > It's trivially simple, but I thought it might be useful to others. > > Jay P. > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
'filesize' patch for humanize
I just added a patch (http://code.djangoproject.com/ticket/2466) that adds a 'filesize' filter, which returns filesizes (from get_XXX_size) in a human friendly way. It's trivially simple, but I thought it might be useful to others. Jay P. --~--~-~--~~~---~--~~ 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: why are the date-based views restricted to only displaying past-events?
On 7/26/06, Tyson Tate <[EMAIL PROTECTED]> wrote: > I'm +50 on this because I'm about ready to jump in to a large calendar > project next week and I'll need this functionality. If no one beats me > to it, I'll try to remember to hammer out a patch next week. > > Any suggestions for how people would like to see this implemented? Well, my initial thought (as I stated in the previous thread) was an 'allow_future' keyword that defaults to False. That way it's backwards compatible. Jay P. --~--~-~--~~~---~--~~ 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: why are the date-based views restricted to only displaying past-events?
On 7/26/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > Hi. > > I was wondering what the rationale is behind having the date-based generic > views only show 'historical' events. > they all seem to have > # Only bother to check current date if the date isn't in the past. > if date >= now.date(): > lookup_kwargs['%s__lte' % date_field] = now > > yes I know I can write my own views, but I'm just trying to understand this > limitation. > Adrian's justification was that the system was built for "archival" purposes. I brought this up earlier in Django-users, http://groups.google.com/group/django-users/browse_thread/thread/5b5d4fa5ad40f7bf/95de22e1e42b5d21 A thread you seem to have participated in :) And no, I haven't had a chance to implement 'allow_future', or anything like that. My immediate need for it disappeared, so it's been pushed to the back of the list. Jay P. --~--~-~--~~~---~--~~ 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: Test framework for end-user applications
On 7/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Unless you can make a particularly convincing case for using an alternative, > based upon some deficiency of unittest that will adversely affect django > testing, I'm inclined to stick with whats in the standard library. > > If the powers-that-be want to override on this issue and declare some > alternative testing framework, feel free to let me know. > > That said, I am not aiming to set up a django testing framework that > actively impedes the use of py.test or nose; if there is anything we can do > to make the two compatible/complimentary, let me know. > Well, I'll step in and give my own +1 (for whatever it's worth) to the use of nose. I've used nose a good deal in the past, and am completely enamored with it. One of the fantastic things about it is that it wraps around unittest, so it's compatible with any unittest suites people might have. Of course, you just using unittest by itself also gets you that, but using nose will save you re-implementing a whole lot of stuff. I'd suggest at least taking a look at it. All the relevant info about it (and some pertinent examples) are pretty concisely described on the project's main page (http://somethingaboutorange.com/mrl/projects/nose/) Jay P. --~--~-~--~~~---~--~~ 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: related object's fields in the admin options
On 7/12/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> So I've got a model resembling:
>
> ==
> from django.contrib.auth.models import User
>
> class ExtendedUser(models.Model):
> user = models.OneToOneField(User)
>
> class Admin:
> list_display = ('user',)
> search_fields = ('user',)
> ==
>
> The admin has a user column but it is sorted by User.id and therefore
> not sorted alphabetically. Nor can you search on the string that
> User.__str__ returns. This makes things very difficult. I think it
> would be nice if the related object's fields were allowed for
> list_display, search_fields, etc. This would be allowed for
> OneToOneFields and ForeignKeys.
You can use functions inside list_display:
class Admin:
list_display = ('get_last_name',)
def get_last_name(self):
return self.user.last_name
get_last_name.short_description = "Last Name"
--~--~-~--~~~---~--~~
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: Feedback on New Middleware
On 7/4/06, Ryan Mack <[EMAIL PROTECTED]> wrote: > Here's my issue: Is simply requiring that these method names be uppercase > enough to distinguish them from non-http method handling methods? I've > created an httpmethod decorator to help further distinguish these methods, > but at times it feels like it adds more complexity than it's worth. My > concern is that, should others begin to use this middleware, someone will > inadvertently create a class method with an all uppercase name and > unintentionally expose a method as an HTTP method. Using all uppercase to distinguish sounds like very bad mojo to me, it's too "magic". Between your two options, I'd definitely go with the decorator. > I'm rather new to Python and Django, and can't seem to make up my mind. > Keep the decorator, loose the decorator, or do something else I've not even > considered? Which is more in-line with the ways of Python and Django? Python has a lot of "conventions" surrounding how you name something, but those are almost always just conventions. For example, double leading/trailing underscores around special methods, using "self" as opposed to "this", etc. Doing something based on whether the method name is all capitals wouldn't fit with any other Python library I've ever come across. It would also break if for some reason people wanted to start assigning the methods to a variable, ie. foo = SomeViewClass.GET Unless you do a bunch of other things, you lose the function name in the assignment. Jay P. --~--~-~--~~~---~--~~ 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: #2217 - Filtering using objects rather than IDs
On 6/30/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > However, since this change could effect people in the field, I thought I'd > check for objections before I commit. > > Comments? I think that personally it will break one or two things for me, but it's a breakage I'm glad to deal with. I'm consistently surprised when I try something like Reporter.objects.filter(article=a) and it doesn't work. It seems so much like it *should* work that I keep forgetting. Jay P. --~--~-~--~~~---~--~~ 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: Generic Relationships/convert_post_data in forms
On 6/23/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > I somewhat missed the whole discussion on generic relation though I get > the general idea. Do they work for ManyToMany relations? And is there > any description of how to use them? > > > but it has a very neat Tag widget for the Admin. > > To be really neat it pretty much requires some more styling to layout > that bunch of input fields. I didn't include such stylesheets into the > package since it depends on a page's layout. > > > http://softwaremaniacs.org/soft/tags/ > > Or more likely: http://softwaremaniacs.org/soft/tags/en/ I think Ian's own post about them is still the best initial resource: http://feh.holsman.net/articles/2006/06/19/django-generic-relations That contains a link to Jacob's tests for them, which illustrates very nicely how to use them. Jay P. --~--~-~--~~~---~--~~ 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: DateField comparison broken?
On 6/19/06, gabor <[EMAIL PROTECTED]> wrote: > > > that seems to be the problem. > it works with postgresql. > > if you want to verify the problem: > > import django.db > print django.db.connection.queries > > this will print out the sql queries django is doing. > > in this case it does something like this: > > select * from main_article where pub_date between '2006-01-16 00:00:00' > AND '2006-01-16 23:59:59.99'; > > if you execute this query directly on the sqlite3 database, it will not > find anything. > > if you repeat this example in postgresql, it works. > > so it seems to be a bug with sqlite3... will dig around a little more. > It felt like a db error, because of *where* it was breaking, but I've not yet looked into the ORM layer, and didn't have time to start digging. Jay P. --~--~-~--~~~---~--~~ 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: validate_full never called?
On 6/17/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > On 6/17/06, gabor <[EMAIL PROTECTED]> wrote: > > > > could you post your model and the relevant part of the view code? > > The relevant model: class Product(models.Model): product_name = models.CharField(maxlength=64, blank=False,validator_list=[good_name], unique=True, primary_key=True) And my view: if request.POST: manipulator = Product.AddManipulator() new_data = request.POST.copy() errors = manipulator.get_validation_errors(new_data) if not errors: manipulator.do_html2python(new_data) When I have the primary_key=True, then the manipulator doesn't catch any errors. It also doesn't call my 'good_name' validator. When I remove the primary_key=True, then the manipulator catches the error, and returns "This field is required." as the field error. Jay P. --~--~-~--~~~---~--~~ 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: validate_full never called?
On 6/16/06, gabor <[EMAIL PROTECTED]> wrote: > > Jay Parlar wrote: > currently you have to use manipulators, if you want to validate the data > that enters your models, see > http://www.djangoproject.com/documentation/forms/ > > later, when validation-aware models will be implemented, this validation > step will happen in the model itself. I do use manipulators, ie. manipulator = xxx.AddManipulator() ... new_data = request.POST.copy() errors = manipulator.get_validation_errors(new_data) but it wasn't catching the empty field. I just assumed that the 'blank=False' would be used by the manipulator during its validation stage. Jay P. --~--~-~--~~~---~--~~ 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: validate_full never called?
On 6/16/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 6/16/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > > I just noticed today that if I have a CharField primary_key, with > > 'blank=False', the system doesn't actually ever validate that the > > field isn't empty. > > The validation stuff isn't finished and isn't intended to be used yet. > Move along, nothing to see here. :) > > Adrian Hehe, ok, I can live with that for now. By "validation stuff" though, what exactly does that include? Keywords passed to the fields in the model? Or anything else I should keep my eyes open for? Jay P. --~--~-~--~~~---~--~~ 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: Improved FileField ideas?
On 6/14/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > > Jay Parlar wrote: > > So what I'm thinking, is to allow something like the following: > > > > class User(models.Model): > > username = models.CharField(...) > > avatar = models.ImageField(upload_to="users/" + self.username, > > erase_old=True) > > > For "upload_to" case I think this will work: > > upload_to="users/%(username)s" > > with a substitution: > > dir = upload_to % obj.__dict__ > > A (little) problem I see with this solution is that data may be not safe > for a filename but Django does some safety replacements for supplied > filenames anyway so it can be used here too. > Right, I always forget about Python's builtin string templating. That's a neat way to do that. > I like your erase_old. The logic (as I implemented it in my views) can > be as follows: > > old_filename = obj.get_FILED_filename() > > if erase_old and >( or ) and >: > os.remove(old_filename) Yep, that's essentially what I was thinking. Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Improved FileField ideas?
So I've been thinking a lot recently about FileField/UploadField, and how restricting they are for any app that might want users to upload files. Namely, the fact that the upload_to can only use strftime() to vary the directories. I did submit a patch (http://code.djangoproject.com/ticket/1994) awhile ago that lets you specify the directory you want, but only if you're willing to manually use the save_XXX_file method in your own custom view. This means of course that you can't use it with the generic views. I think a fairly typical use case for a generic view would be an User Account creation form, for a forum, or some other app. A lot of times, you want the user to be able to upload an avatar or other files. Or maybe something like a where users can upload attachments with their posts. The way things currently stand, there's no way to give each user their own directory in the filesystem (unless you use my patch, but it won't work for generic views). And even worse, files can get "lost" if they upload two files with the same name. The old one won't be pointed at in the database anymore, and the new one will have an "_" at the end of it. Of course, if you drop to a lower level (and are using my patch), you can manually remove the old file, but that doesn't seem very Django-nic (to borrow a term...) So what I'm thinking, is to allow something like the following: class User(models.Model): username = models.CharField(...) avatar = models.ImageField(upload_to="users/" + self.username, erase_old=True) Of course, we can't use 'self' in the field declarations like that, but I think the idea is clear enough. And the erase_old=True could mean something like: "If we're updating a row in the table, delete whatever the old file was" Does anyone have any good API ideas for this? Am I the only one that sees the use in it? I'd be willing to try writing the code, but I'd appreciate some community feedback before getting started. Thanks, Jay P. --~--~-~--~~~---~--~~ 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: the so-called [AUDIT]
On 6/2/06, Carlo C8E Miron <[EMAIL PROTECTED]> wrote: > > On 6/2/06, Julian 'Julik' Tarkhanov <[EMAIL PROTECTED]> wrote: > > > > I would advise all respected Django contributors to follow the path > > mentioned here: > > > > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/138966 > > and maybe also > > http://www.encyclopediadramatica.com/index.php/Ilias > > ;) Something seemed "off" the whole time with that guy, but he seemed to be doing too much research into Django to be a real troll. He must have a LOT of free time. Jay P. --~--~-~--~~~---~--~~ 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: Enable Django Quick Start / Database Evolution Support
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > > And an efficient tool should assist a user to become productive immediately. > > http://case.lazaridis.com/multi/wiki/Product#Functionality > > There are webframeworks which provide this functionality. > What exactly are you basing that claim "an efficient tool..." on? There are a multitude of tools available that are incredibly efficient, but require a large learning curve (think high end video/audio editing applications, scientific computing apps, etc.). I think when you focus *too* much on being productive immediately, you often lose out in the long term. I'm not saying that Django shouldn't have some effort on that, after all, it's the web framework for "perfectionists with deadlines", but you have to beware of blanket statements like you made. They hurt credibility. Jay P. --~--~-~--~~~---~--~~ 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: Patch review procedure?
On 5/31/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > Could you trust a patch when some other developers have positively > reviewed it? This might take a time until your ideas of proper patches > have been "revealed", but then we'd have a more or less peer review > system. And it could get the routine jobs off your hands. > That's an interesting comment, and I think that in the open source world, Django is (unfortunately) in kind of an unique situation. *Most* open source projects start out very small, and open source from the get-go. We were lucky that when Django was open sourced, we immediately got access to a fantastic working system. Most other open source projects have to build up to the point of being a fantastic working system. And in that time, they gain more knowledgeable developers, and a sense of patch and coding "style". (As well as levels of trust for long time contributers) I guess this is just going to be a growing pain for Django, but one I'm sure we're all willing to work through. Jay P. --~--~-~--~~~---~--~~ 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: Patch review procedure?
On 5/31/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > It's the latter. Me, I generally have one afternoon a week in which I > focus on clearing out patches and tickets, plus weeknights as my > schedule allows. I'm pretty sure Jacob works the same way, although he > has been *super* busy traveling and moving lately. Ideas for improving > this system would be much appreciated! Would there be interest from you core guys for setting up some kind of monthly "Django Bug Day", like the python-dev guys do every once in awhile? Because of the smaller number of people with commit access, maybe on a bug day a branch could be setup, and everyone participating could get access to it. Then for the day we all make changes and commits to that branch, then meet up a week later to discuss if it should get pushed to the head? I'm just pulling ideas out of the air here. I have a lot more experience in corporate environments than I do working with large groups on an open source project, so I'm not sure how these issues are usually handled. Jay P. --~--~-~--~~~---~--~~ 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: Patch review procedure?
On 5/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi Jay, > > svk is your friend. It won't help with getting patches reviewed, but it > does make keeping a tree of local patches almost painless. Here's my > recipe: > > # set up mirrors of your repository and django trunk > # and copy django trunk under vendor/ in your repository > svk mirror http://code.djangoproject.com/svn/django/trunk/ > //mirror/django > svk mirror http://your.svn.repos/project //mirror/project > svk cp //mirror/django //local/django > svk cp //mirror/project //local/project > svk co //local/project > cd project > svk mkdir vendor > svk cp //local/django vendor/django > svk ci vendor > svk push > > # make changes to vendor/django and push them back to your repos > cd vendor > emacs django/django/core/management.py > > # later pull an update > svk sync --all > svk pull //local/django > cd django > svk smerge //local/django . > svk ci -m "Merged django trunk to ... " > svk push > > # see what you've changed > svk diff -v //mirror/django . > > Works like a charm. (I'm hardly an svk expert, though, so there are > probably easier/less verbose recipes for doing the same thing.) > > JP > If only Darcs were the norm... Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Patch review procedure?
Just wondering what the procedure is for getting a patch accepted? I submitted a patch (http://code.djangoproject.com/ticket/1994) a week ago, and have had no feedback on it so far. Is there some kind of monthly IRC meetup where pending patches are discussed? Or is it just when the core developers have free time for it? I'm just going to keep running with the patch locally, but I hate to run software that's different that the trunk. Thanks, Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
