Re: get_FIELD_filename() in pluggable FileField backends

On 9/8/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I'd say something like django.core.filesystems would be a good idea > (though I'd call it django.core.filestorage and paint the bikeshed > yellow.) I have pretty much zero preference on what it's called or where it goes, so yellow sounds f

Re: get_FIELD_filename() in pluggable FileField backends

I submitted a new patch, which moves the backend code into django.core.filestorage and tweaks a few minor things. Most importantly, this new patch includes documentation in the form of a new document, files.txt, and some minor updates to model-api.txt and db-api.txt. The documentation probably is

Re: Add import location of objects to docs?

While not exactly what you're looking at, something I had considered some time ago was putting together a set of wiki articles that are geared toward more of a quick-reference documentation. I put together articles for HttpRequest[1] and HttpRespone[2], but never got any further than that. As you

Re: Using Trac's "assigned" feature properly

On 9/9/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > FYI, in order to "accept" a ticket you need an account and need to be > logged in. To create an account, go to > http://djangoproject.com/accounts/register/, and then log into trac > (using the "login" link at the top right). So, just so I

Re: django on jython (new version)?

Okay, I guess I'm not much on doing fun stuff with RSS, but I went ahead and set up a Yahoo Pipe[1] to keep track of the various blogs that are currently (or will be) dealing with the topic of Django on Jython. If anybody else is writing on the subject, let me know and I'll add you to it. -Gul [

Re: Ticket #5333: add an assertContext method to Django's TestCase

On 9/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Valid point - however, in practice, the same context is passed to > multiple templates. There are some edge cases (e.g., a view with two > calls to render_to_template) where this isn't the case, but I wouldn't > consider them to be the c

Re: Many-to-many relationships with additional columns

On 9/10/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote: > Marty's suggestion looks promising and seems to have a good bit of > support from the core devs. It's been a few months, and I am > wondering if there has been any movement on this. This particular item has been low on my list of prioritie

Re: Signals in ManyRelatedManager

On 9/11/07, Ludovico Magnocavallo <[EMAIL PROTECTED]> wrote: > I really need this feature, could you tell me if it has any chance of > being committed, or if there's a different way of doing the same thing > that I did miss? I'm hoping to look into revamping some ManyToMany stuff during the sprin

Re: accessing db api from models.py breaks apps/models loading

I'll be looking into this a bit this week, hopefully I can get something nailed down before the sprint. It's rearing its ugly head in one of my projects that really can't afford to have models disappearing from the admin. I'll post more when I know more. -Gul --~--~-~--~~

Re: proposal: helper functions for validation

I'll chime in just for a few cents here. First, I think it's worth noting that most Python programmers find little value in how many characters they have to type. Sure, Python is generally less verbose than many other languages, but only to the extent of making it more readable. So kep readabilit

Re: proposal: helper functions for validation

On 9/11/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > > About validate_exception, this is the signature of the corresponding > method in unittest: > > *assertRaises*( exception, callable, *args, **kw) > they have removed message, but since args and kw will be passed to > callable, these are the on

Re: Signals in ManyRelatedManager

I've come up with a considerably different approach to this, which offers more flexibility, and also solves a problem I've had when it comes to ManyToManyField. Basically, instead of dealing with signals, and worrying about pre/post and whether or not you can prevent stuff, I broke out some bits o

Re: Many-to-many relationships with additional columns

On 9/11/07, Tai Lee <[EMAIL PROTECTED]> wrote: > This seems to work, but is it missing out on some of the niceties / > helper methods of the proposed M2M? What would be the benefits of the > suggested new method over this? Yes, that method works, and that's the recommended way to go for now, but

Re: Signals in ManyRelatedManager

On 9/12/07, Ludovico Magnocavallo <[EMAIL PROTECTED]> wrote: > The only advantage I see in adding signals (but I'm not an expert of > Django internals) is that it's pretty painless as it's five-lines patch, > and it leaves all the other code unchanged. I'm definitely still considering signals, be

Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 9/16/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On 9/16/07, James Bennett <[EMAIL PROTECTED]> wrote: > > * Lots of things related to FileField which would be fixed by the > > pluggable backends proposal. > > s/would/will/ -- I'm gonna try to have this wrapped up in the next couple >

Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 9/17/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > While it's true those are three separate issues, it makes more sense > to me to solve 'em all in one fell swoop. Something like #5361 has > been on my radar for quite some time now (file storage right now is > something of a pain in a larg

Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 9/17/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I think I prefer exposing file attributes as properties instead of > methods (so ``myobject.file.name`` instead of > ``myobject.file.get_filename()``. It just feels a bit cleaner, and it > will allow setting in circumstances where appropri

Re: Visual recogintion of Django website

Regardless of whether it should be on the site or not, I think there's an fundamental open-source concept missing from this conversation. If you think the Django site needs a favicon, a good first step would be to provide one. That's not guarantee it'll be used, of course, but if it's so important

Explicit Relationships

I was hoping to bring up some ManyToMany enhancements at the sprint, but I didn't manage to participate after all, so they went unvoiced. Instead, I'll bring up some thoughts here and see what you guys think. I apologize in advance for the length of this post, but if you're interested in seeing M2

Re: Explicit Relationships

On 9/17/07, Vsevolod Solovyov <[EMAIL PROTECTED]> wrote: > > This would allow custom values for db_table > > (currently impossible for standard M2M) > ManyToManyField takes db_table as argument. Description: > > The name of the table to create for storing the many-to-many data. > If this is no

Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 9/17/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Now, a SSH/SFTP backend... that would rock. Well, as seems to be the case, now that you've mentioned it, we'll all expect you to write it. :) Hopefully I've made things easy enough for you, though. -Gul --~--~-~--~~-

Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 9/18/07, Johan Bergström <[EMAIL PROTECTED]> wrote: > What is wrong with using FTP for intranet file shuffling? I don't > think frameworks should decide or advocate how you design your > application from a security point of view. Offering both SFTP/FTP with > documented recommendations towards

Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 9/18/07, Johan Bergström <[EMAIL PROTECTED]> wrote: > Since FTP and SFTP are so closely related i still think that the 'why' > or 'how do i' would show more often than not if FTP was omitted. My > view of frameworks is generally based on DRY - but i guess at some > point it is wiser to pick 'be

Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 9/18/07, Michael Scott <[EMAIL PROTECTED]> wrote: > Is that not violating DRY in itself there? I mean we're gonna end up with > alot of people writing the documentation with it, just as much as writing > the FTP module itself. I think this is something where we're always going to > have the "re

Re: Explicit Relationships

On 9/18/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > First off - I acknowledge the underlying problem (making m2m > intermediate models easier to use), and I would like to see a > solution. However, while I'm sure your propsed solution could be made > to work, I'm not sure it would be a go

Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]

On 9/17/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > I'll get a new patch together tonight, including a get_filename() that > returns None if the backend doesn't implement it. That should clear > away the last remaining worry I had about maintaining existing > fun

Re: Explicit Relationships

On 9/19/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > It sounds like you're talking about making the m2m table a 3 foreign > key affair (with the third foreign key referencing the intermediate > data) rather than just adding 2 foreign keys (from and to) to the > intermediate model. I'd be i

Re: Explicit Relationships

On 9/19/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > class Membership(models.Model): > def add(self, user, guild): > if user.guild_set.count() > 3: > raise Exception, "Maximum guild membership has been reached." > super(Membersh

Re: Looking for discussion on #5535

On 9/19/07, James Bennett <[EMAIL PROTECTED]> wrote: > David Cramer has asked that Django's ORM lookup syntax be changed to > allow a single underscore for a foreign key lookup; in other words, > the following two examples would become equivalent: > > UserProfile.objects.get(user__id=3) #Currently

Re: Do you need more committers/triagers?

One thing we have to keep in mind here is that people regularly use the SVN version of Django, so it needs to be working as well as possible, all the time. This is unlike many other projects, where the repository (be it SVN or CVS) is always considered a work-in-progress, where users are urged to

Re: django on jython (new version)?

I'm definitely not on the cutting edge of Django on Jython here, but I started working out a servlet handler, so that once we get things working fairly well, we can see how it works outside the test server. I haven't really tested it yet or anything, but it seems like it should work fairly well.

Re: django on jython (new version)?

On 9/20/07, Leo Soto M. <[EMAIL PROTECTED]> wrote: > Maybe I completely misunderstood you, but what would be the difference > with modjy ? I hadn't known about modjy! That looks excellent, so we should be able to reuse the existing WSGI handler, even in J2EE environme

dbsettings and #2438

During the sprint, Malcolm informed me about #2438, and that it was the reason some models were disappearing from the admin when using dbsettings. I've spent some time trying to figure it out, since I had a setup that was exhibiting the problem, but so far I haven't come up with anything. So, in

Re: official shop of django?

On 9/25/07, Xan <[EMAIL PROTECTED]> wrote: > I think that this official shop were good for promoting django and for > financing this great project (personal opinion) I know I've found myself jealously desiring one of those "I wish I were made with Django" t-shirts. :) -Gul --~--~-~--~--

Re: Schema Evolution status (official)

I won't get into the discussion on features or implementation yet, but I do have to agree that working code speaks volumes compared to descriptions. I'll have need for schema evolution in a future project, so I've been following these discussions, and I've completely lost track of who's working on

Re: Another urlpatterns proposal (add method column)

I can't say I'm a big fan of this proposal, personally. While I can understand where you're coming from, it smells a bit too much like J2EE's doGet/doPost stuff for my taste. On a more objective note, though, would that mean that every urlpattern would require an HTTP method, or could it be ignor

Re: Another urlpatterns proposal (add method column)

On 10/2/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > That said, I think there are probably others out there like you who > would want this, and there's actually nothing stopping you from > releasing it as a separate app, or even a snippet. Well, looks like I misspoke. It se

Re: Still no favicon - Re: Visual recognition of Django website

I'll preface my thoughts with the disclaimer that I have authority here, I'm just somebody who's been watching this discussion. First, this isn't a bug in any sense of the word. It has nothing to do with any breakage of code. It's a feature request. Let's just get that straight. Feature requests

Re: Decoration and aliasing

> Since Django already includes curry, which is roughly the same as > functools.partial, it'd be pretty easy to back-port "wraps" to Django. > > Is there any interest in a patch that modifies Django's built-in > decorators to use functools.wraps in order to preserve things like > view function doc

Re: Decoration and aliasing

On 10/4/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > While I'm at it, I think aliasing functools.partial to > > functional.curry would be good, assuming functools is available. > > Providing the functionality is identical. Otherwise it's really, really > painful to work out why things

Expanding the flexibility of URL resolution

Apologies in advance: This is a long email, and I may tend to ramble. Try to bear with me, please. In testing out a framework for creating Netvibes widgets (just to see if I could), I had what I thought to be a great idea for resolving URLs to methods on a Widget instance. Essentially, each view

Re: Expanding the flexibility of URL resolution

On 10/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I can cheat a little bit here because I've thought about this a lot in > the past. So this is slightly more than just a shot from the hip, > despite the quick response time. This is all very hypothetical, because > I've only ever done tho

Re: Expanding the flexibility of URL resolution

On 10/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > I'll admit, I'm not a big fan of anything that could be gained by > passing the request to the resolver. I forgot! After [4237] went in, people can specify a custom resolver based on the request anyway. So once resol

Re: Request exception handling and exception middleware

I don't know a whole lot about exception handling in middleware yet, but I like the idea of making it easier to inject more functionality into the default handler. For instance, I like the postmortem for template loader errors, but I've also wished I could include something like that for my own ap

Re: how practically to extend your models?

Also, for what it's worth, it's quite a leap to go from "one-to-one relationships have problems" to "Django is not made to the purpose of code reuse". There are many ways to reuse code in Django, without having anything to do with one-to-one relationships, or even model relationships at all. Thing

Re: newforms subclassing

I think a decent solution here would be to for somebody to write a helper function with the purpose of merging multiple forms in the way people seem to expect multiple inheritance to work. It wouldn't be part of Django proper, I imagine, but it would make a useful snippet to pass around when peopl

Re: Is currency obj.delete() behaviour slightly broken?

I had wondered at the time if it was better to just add the PK as an argument to the post_delete dispatch, rather than having it available on the object itself. Something like "old_pk" I suppose. I didn't have any interest in it at the time though, so I left the discussion to those who actually ca

Re: Documentation restructuring

On 10/19/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On Oct 18, 2007, at 8:55 PM, Marty Alchin wrote: > > > On 10/18/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > >> I'd like to improve the quality of Django's documentation. > > >

Re: Documentation restructuring

On 10/18/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > I'd like to improve the quality of Django's documentation. I can't say I'm surprised to hear that. I've heard several requests for changes in the documentation. Heck, I think I've even been one of them, some time ago. I like the idea of ap

Re: Documentation restructuring

On 10/18/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I may have communicated poorly, as usual. I think we'll get lots of > information and some of it will be of great value. What I do think is > important is that we have to manage expectations a bit, because there > will be people who'll t

FileField question

In response to some recent questions regarding FileField usage, I thought about including a way to format the filename based on details from the model instance itself. It's looking like it' be best to add an argument to FileField, called 'filename' perhaps, which takes a format string, like so (pa

Re: FileField question

On 10/23/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Currently, get_filename uses os.path.basename, and after filestorage > > goes in, get_available_filename will do the same. This means that any > > directory information is lost, unless it's preserved separately. It's > > possible, but

Re: FileField question

On 10/24/07, Thomas Guettler <[EMAIL PROTECTED]> wrote: > I am one of the people who asked for this. I only want to use the > primary key for a directory name. I think a filename is not enough: > I don't want to store the files under MEDIA_ROOT. Otherwise you can't > use access control, since the

Re: FileField question

Okay, just a quick update. I don't have a new patch ready yet, because I wanted to outline a couple things and ask another question. I've implemented the callable method for determining filenames, including the ability to include a subdirectory in the filename. Also, ignore my comment about reusin

Re: FileField question

On 10/27/07, Justin Driscoll <[EMAIL PROTECTED]> wrote: > Any reason not to have upload_to accept a string OR a callable and function > accordingly? Hrm, to be honest, I hadn't really considered that. To me, upload_to makes the most sense as a directory path only, rather than including a filename

Re: FileField question

On 10/28/07, Justin Driscoll <[EMAIL PROTECTED]> wrote: > I may be missing something but lets say when you pass a string to > "upload_to" it functions basically as it does now, however, if you pass a > callable it takes the return value (the full relative path of the file, > including the filename

Re: FileField question

On 10/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I haven't been concentrating too much, since I'm pretty overloaded with > other things (both Django and real life) at the moment. But my general > impression is in line with yours, Marty: having two attributes

Re: FileField question

On 10/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Aren't you still left with one option for upload_to and one for > specifying the full details of the filename in this version? Two options > is at least twice as many as we need.We have to live with (which means > maintain, document and

Re: FileField question

On 10/28/07, Yuri Baburov <[EMAIL PROTECTED]> wrote: > How about introducing new argument, and allowing to use only one or another? > > so, variant 1 (backward-compatible one): > my_file = models.FileField(upload_to="%Y/%m/%d") > > variant 2 (works only in new revisions): > my_file = models.FileFi

Re: Choice lookups

Wow, that's an interesting idea. I don't think I'd use it very often, but I definitely like the idea. It would add a little bit of overhead beyond the existing, but that's only when people actually use it, and I expect that won't be terribly often. This seems like the kind of thing that would be

Re: Choice lookups

James, I think you've managed to hit (what I'd consider) the perfect stride there. You have to import Entry anyway, so by making your constants class attributes, you avoid the extra import requirement. I hereby retract my +0 in favor of a -0. Either way, I'm still stuck at "meh." -Gul --~--~---

Re: Choice lookups

On 10/30/07, James Bennett <[EMAIL PROTECTED]> wrote: > Though on further reflection, I think Jeremy's asking for something > that's legitimately useful: it'd be nice to have some way to accept > the human-readable value (say, in a URL) and use it to do the lookup > with that. Hrm, I hadn't reall

Handling non-string values during serialization

Hey everyone (Russ in particular), it's me again. While working on DurationField recently, I noticed what I thought to be strange behavior during serialization. The XML serializer worked as I expected, using the number of seconds as a decimal, while the JSON serializer used the output of str(), w

Re: Handling non-string values during serialization

On 11/5/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > It's not really appropriate for serialization and we really need a > to_string() method on Field subclasses that serialization uses. Agreed. I'll just get DurationField to accept timedelta's str() output, that should get things working r

Re: Handling non-string values during serialization

On 11/6/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Malcolm has pretty much nailed this one already. However, for the > historical perspective: flatten_data is an artefact of the oldform > era, and the original serializers were written before newforms. The > discrepancy between the Python

Re: ForeignKey(unique=True) and ForeignRelatedObjectsDescriptor

On 11/6/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On 11/6/07, Thomas Guettler <[EMAIL PROTECTED]> wrote: > > > > You can use a property. Code not tested: > > Of course. I just have about 30 places to do that legwork, which seems silly. Well, you could write up a function to create the prop

Re: form_for_instance and form argument, empty form?

> > On 11/7/07, David Larlet <[EMAIL PROTECTED]> wrote: > >> Hi all, > >> > >> I'd spent a long time finding that bug but I want to be sure before > >> submitting it on Trac. If you pass a form argument to form_for_instance > >> like that: > >> > >> forms.form_for_instance(foo, form=FooForm) > >>

Re: form_for_instance and form argument, empty form?

This should probably be asked on django-users, as it's more about how to use form_for_instance() than any internal development. And yes, that means I don't believe it's a bug, and I'll gladly explain more on django-users so more people can hear it. -Gul On 11/7/07, David Larlet <[EMAIL PROTECTED

Re: form_for_instance and form argument, empty form?

On 11/7/07, David Larlet <[EMAIL PROTECTED]> wrote: > Unfortunately, what happens with my Form is exactly what I'd like to do: > create a generic form from a Form class which define fields (with > widgets, etc) and methods and which is initialized with the content of > the instance. That seemed mo

Re: ANN: Django sprint, December 1st

On 11/7/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > We'll hold the sprint Saturday, December 1st here in Lawrence, KS, and > virtually around the world. Dang it! Why do you guys always plan sprints on days I already have something planned? Couldn't you at least check with me first? :) Only

Re: ANN: Django sprint, December 1st

On 11/7/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Yeah, we wanted to get one in before PyCon, and it turnned out that > Dec. 1st was going to be the only time we could slide it in. Especially since I see Malcolm's going to be there in person. That's gotta be tough to plan around. > We *

Re: ANN: Django sprint, December 1st

On 11/7/07, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > > On 08-Nov-07, at 6:47 AM, Kenneth Gonsalves wrote: > > >> Django bells, Django bells, > >> Django all the way; > >> Oh what fun it is to code > >> In a well-designed dynamic language! > > > > In an open source way! > > All night and da

Re: form_for_instance and form argument, empty form?

On 11/7/07, SmileyChris <[EMAIL PROTECTED]> wrote: > Actually, I see no good reason why you shouldn't be able to use a Form > as the SuperClass of your form_for_* form. Yeah, I was trying avoid the issue of "should" of "shouldn't" and just point out what was going on. -Gul --~--~-~--~--

Re: ModelForms

Fair warning: I haven't been following this very closely, so I'm probably way out in left field here. Feel free to look strangely at me after I mention this. Would it be possible to use a factory pattern for ModelForm? class Article(models.Model): title = models.CharField(max_length=255)

Re: ModelForms

On Nov 9, 2007 9:57 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > The only thing it doesn't handle yet is how to remove > fields from the customized form, but this might be as simple as > assigning the field to None or some new ExcludedField class or > something. I actua

Re: ModelForms

On Nov 9, 2007 10:07 AM, Smel <[EMAIL PROTECTED]> wrote: > PS : > http://smelaatifi.blogspot.com/2007/08/declarative-forms-django-newforms.html I'd say I'm -1 on including admin-style field declarations to forms. I'm of the mind that, if you need that level of design on a custom form, just write

Re: ModelForms

On Nov 9, 2007 12:42 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > Why not just do this? No need for any special new fields at all. > > class Article(models.Model): > author = models.ForeignKey(User) > title = models.CharField(max_length=255) > body = models.TextFi

Re: Patch polishing

On 11/11/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > As for close rates and other useful metrics, yeah, those should be > more visible. :) I've wondered about building a Trac plug-in to monitor those types of things and provide reports. There's a wealth of information in Trac just waiting to b

Re: ModelForms

On Nov 12, 2007 3:37 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > class MyForm(ModelForm): > extra_field = SomeField() > > class Options: > model = MyModel > fields = ['list', 'of', 'field', 'names'] > > def formfield_callback(db_field)

Re: ModelForms

On Nov 12, 2007 4:05 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > class Article(models.Model): > title = models.CharField(max_length=100) > body = models.TextField > > class ArticleForm(models.Model) > body = MyCustomBodyField() # override the default formfiel

Re: Model post_save doesn't play well with Model.save overriding

On Nov 14, 2007 12:21 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Jeremy's still got a valid problem, though, but I'm not sure > reintroducing pre_save() and post_save() is a necessary step yet. > Hopefully there's something else we can do. I wonder if there's a way to modify PyDispatcher

Re: Model post_save doesn't play well with Model.save overriding

And, of course, adding a queue to the dispatcher would decouple this solution from save() and make it usable in any signal handling code. -Gul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" grou

Re: Model post_save doesn't play well with Model.save overriding

On Nov 14, 2007 9:37 AM, Forest Bond <[EMAIL PROTECTED]> wrote: > This is neat and all, but I don't think at actually solves the problem at > hand. > If save is not overridden, when does queue.dispatch() get called? If save isn't overridden, queue.dispatch() wouldn't be called, because the queue

Re: Model post_save doesn't play well with Model.save overriding

On Nov 14, 2007 9:44 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > The queue.dispatch is only necessary if dispatcher.queue has been > invoked; if save is not overridden, dispatcher.queue is not invoked. > Right? Correct. > Even so, it seems to me that the queue approach would need to be thread-

Re: Model post_save doesn't play well with Model.save overriding

On Nov 14, 2007 10:04 AM, Forest Bond <[EMAIL PROTECTED]> wrote: > I'm not entirely convinced the overhead is all that terrible, especially given > that: > > * Database writes are less frequent than reads. > * Anybody overriding save is probably adding more overhead than this anyway. > > Maybe we

Re: Model post_save doesn't play well with Model.save overriding

On Nov 14, 2007 8:55 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > I dunno, that's all just off the top of my head, but maybe it could work. Well, I did a little digging and put together something that seems to work. And when I say "seems to work", I mean that there

Re: django-gadgets

On 11/14/07, Marinho Brandao <[EMAIL PROTECTED]> wrote: > > Hi all, > > I created django-gadget [1] contrib. I see a great future for Google > Gadgets with iGoogle, Google Desktop, OpenSocial and Android > applications, this is my motivation to create it. > > I think it can be util to be added to

Re: Problems with FileFields/ImageFields

On Nov 16, 2007 12:12 PM, Marc Garcia <[EMAIL PROTECTED]> wrote: > First one is about how to delete content in a FileField. With a > example: > > I've a model: > > class Person(model.Model): > name = models.CharField(maxlength=32) > [...] > picture = models.ImageField(upload_to='pictur

Re: django-gadgets

On Nov 16, 2007 2:55 PM, Marinho Brandao <[EMAIL PROTECTED]> wrote: > nice job :) if I understand, django-modular is a app to allow websites > are widgets container, and provide too some widgets functionality, > right? all based on UWA API, I'm right? No, django-modular has nothing to do with the

Re: [SECURITY] Session Hijacking in Django

On 11/26/07, David Ross @ Wolfeon <[EMAIL PROTECTED]> wrote: > environment, and am rather disgusted at the current state because the > ticket was opened 11 months ago. > > http://code.djangoproject.com/ticket/3285 > > My recommendation is to incorporate code in the default session module > which i

Re: [SECURITY] Session Hijacking in Django

On 11/26/07, James Bennett <[EMAIL PROTECTED]> wrote: > [1] Actually, a "secure" web application is possible. It just starts > with not ever connecting the application to the Web. Ideally, the > server on which the application code and database is kept will also be > stored inside a nuclear-harden

Re: Session Hijacking in Django

On Nov 26, 2007 7:47 AM, David Ross @ Wolfeon <[EMAIL PROTECTED]> wrote: > I try not to use by IP due to the problem you specified. Glad to hear it. > The way I think of the second cookie, is more like a 2nd password. > Sure, there is a possibility of a brute force with it to, but it is > less l

Re: Session Hijacking in Django

On Nov 26, 2007 8:30 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > I'm not sure what makes you believe that two cookies are more secure > than one. Two n-bit strings are just as secure as one 2n-bit so a > simple answer would be: make the session ID twice as long. And that's exactly what the s

Re: Ticket #5989

I regret not having a recent trunk to test this with, but I think you'd be better off storing th evalue in the object's namespace dictionary instead. I've recently outlined[1] how this works, and you can also see a great example of it in GeoDjango[2], also linked from that article. Essentially, r

Re: Session Hijacking in Django

igned cookie code? > > On Nov 26, 4:48 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > > On Nov 26, 2007 8:30 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > > > > > I'm not sure what makes you believe that two cookies are more secure >

A few questions about FileField

Gang (especially Jacob), I made a lot of progress on FileField at the sprint, but I have a few things to go over before I submit a new patch for review. Jacob, you recommended that, in the case of an FileField attribute that doesn't have a file with it, accessing the attribute should return None

Re: A few questions about FileField

There is one other question I've been meaning to ask for a while. As would be expected, this FileField work adds a good amount of code to db/models/fields/__init__.py, including 3 new classes, which aren't even Fields themselves (but they're needed to make the Fields work). If I get my way, and Dj

Re: Django 1.0 features -- the definitive list

On Dec 3, 2007 2:26 PM, James Bennett <[EMAIL PROTECTED]> wrote: > I've got some half-assed code for this lying around actually; I'd > envisioned something like 'django.views.generic.wsgi.wsgi_application' > being a way to simply drop any WSGI application into a Django URLConf. I don't know much

Re: FileField overwrite (Ticket #4339)

Any time I see "FileField" in a subject line, my ears perk up, so I'll put in my thoughts on this subject. On Dec 4, 2007 10:43 AM, Marc Garcia <[EMAIL PROTECTED]> wrote: > I've seen ticket #4339 ( http://code.djangoproject.com/ticket/4339 ) > about allowing django users to create FileFields or I

Re: A few questions about FileField

One other question (for now). I just did a ticket search for FileField, and I found a few tickets (#5655, #5619 in particular) that seem to be legitimate beefs, but their patches rely on pre-#5361 code. Should I consider #5361 to be on par with Malcolm's (many) refactors and try to roll fixes for

<    1   2   3   4   >