Re: Proposal: deprecated Model.__init__(*args)

In the worst case, generating a kwargs dictionary from an args tuple isn't really all that difficult. kwargs = dict([(cls._meta.fields[i].attname, v) for (i, v) in enumerate(args)]) Seems like any code which explicitly needs to handle tuple instantiation (likely the minority) can supply a

Re: Proposal: deprecated Model.__init__(*args)

On Jan 29, 2008 3:13 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Thoughts? I haven't run into any problems with this as of yet, but I'd like to wholeheartedly support this move. I was sincerely amazed when I noticed that models could be instantiated either way, and I couldn't think of a

Re: S3 file storage

On Jan 16, 2008 12:35 PM, Ben Ford <[EMAIL PROTECTED]> wrote: > Hi Marty, > What's your feeling about how much work is involved? I might be in a > position to help out and his is something that I'd love to see! > Ben Feel free to take a look at the code as it stands, to answer that question.

S3 file storage

Hey all, I finally got around to creating a ticket[1] for an S3 file storage backend. Yay! Of course, it's very, very broken at the moment. I haven't touched it since the last sprint, where I was trying to switch from Amazon's own library to boto. I don't use S3 though, so even if I did finish

Re: Jython sprint at PyCon

On Jan 7, 2008 12:45 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > FYI, there will be a Jython sprint at PyCon, with a specific emphasis > on getting applications running, including Django. Hrmph. Django sprint, possible Satchmo sprint, and now a Jython sprint. I expect I'll only work on Django

Re: signals

A slight amendment. I like your idea of moving registration and triggering into methods of the signal object itself, though that does then require that signals support a particular API, which currently isn't a requirement. Providing a base "Signal" class would, of course, help with this, but I

Re: signals

On 1/4/08, Brian Harring <[EMAIL PROTECTED]> wrote: > One additional optimization point for signals is deciding whether > connect(Any, f1) > connect(Any, f2) > > Must execute f1, f2 in that explicit order- internally, dispatcher > uses some nasty linear lookups that could be gutted if f1/f2

Re: M2M intermediary models

On 12/29/07, fietske <[EMAIL PROTECTED]> wrote: > this post is a response to ticket 6095. I'm not championing #6095, but I do have opinions on this, so I'll voice them here for the archives. > In relational modeling theory ALL tables (or better: relations) > are first class citizens. What's

Re: newforms Form.fields.keyOrder

On Dec 28, 2007 3:04 PM, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > I have a use case where a Form superclass includes fields at the top > and bottom of the form, with the subclasses providing the fields in > the middle. Obviously, there's no easy way to fix the ordering using > simple

Re: About applications "registration" or something like this

On Dec 28, 2007 5:19 AM, Marinho Brandao <[EMAIL PROTECTED]> wrote: > when I said "a place to put in applications", I did not saying a hard > place to put the applications, but a more flexible way to import them > from. The solution could be a registration (i.e like template tags) by > an kind of

Re: Finally, an updated FileField patch!

On 12/19/07, simonbun <[EMAIL PROTECTED]> wrote: > The only thing I was wondering is how #2070 is affected by all this? > I'm not sure if this has come up before; a search in the archives > didn't produce anything useful. There's obviously a slight relation since #2070 would need to commit files

Finally, an updated FileField patch!

Gang, I've updated the patch on #5361, so that it now includes a variety of tweaks and updates that I've been working on since before the sprint. Jacob's help during the sprint was great, but I've run across a variety of other issues[1] since then, and I did my best to make decisions that I felt

Re: Cache Invalidation Proposal -- CachedModel

On Dec 13, 2007 1:16 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > ...Perhaps IRC or chat would be good here? Just make sure you post the results of said chat so the rest of us can see. :) -Gul --~--~-~--~~~---~--~~ You received this message because you are

Re: Cache Invalidation Proposal -- CachedModel

On 12/7/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote: > > FWIW, I'm interested in this approach. > > Same here. I'm planning to look at this on Monday, but am very much > interested. I haven't given any thought to how caching should work internally, but this approach seems on par with how the

Re: Little change for FileField

On 12/7/07, Marc Garcia <[EMAIL PROTECTED]> wrote: > Hi guys (specially Marty Alchin I think)! You remembered me! > I've realized about a little issue with FileField in admin. Issues are > invalid html code in widget (unclosed tag and invalid target > attribute), and some

Re: Fixing app_label

On Dec 7, 2007 12:56 PM, Vinay Sajip <[EMAIL PROTECTED]> wrote: > this be allowed/disallowed/checked for? As for standard template > loading, there's no reason that the standard template loading > (app_loader) code could not be modified to work with App instances, > using whatever logic to use

Re: Fixing app_label

On Dec 5, 2007 2:48 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Great to hear this is gaining some momentum. I'm not a fan of the > patch on 3591, as it goes only halfway (by adding the app() function), > stopping short of a full, elegant solution. The approach I've been > wanting to take is

Re: Fixing app_label

On Dec 5, 2007 4:00 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > It's *extremely* useful to be able to inspect settings files *without* > triggering imports of all INSTALLED_APPS -- I've got at least a dozen > utilities that operate on multiple sites by introspecting various > settings

Re: Fixing app_label

On Dec 5, 2007 12:55 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > http://code.djangoproject.com/ticket/3591 has been following this > problem (and the other, related ones). The patches there look > relatively good and the tests appear to pass, but I'm concerned about > the level of

Re: Problems with concurrent DB access and get_or_create()

On Dec 4, 2007 2:21 PM, Travis Terry <[EMAIL PROTECTED]> wrote: > exception escape, then everywhere I call get_or_create() will have to > implement a very non-DRY piece of identical code to handle the situation. I won't get into the issue of whether this should or shouldn't be in core, but you

Re: FileField overwrite (Ticket #4339)

On Dec 4, 2007 11:46 AM, Marc Garcia <[EMAIL PROTECTED]> wrote: > I agree on not commiting patches to a module that will be rewrite > soon. I hope that you find the way to allow that feature on new > version. I guarantee you it'll be possible. I just hate how ugly it'll look, unless I find a way

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

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

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: 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

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,

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

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

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

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

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

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 =

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: 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 a

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

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"

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

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

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

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 =

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

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 actu

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: 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

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: 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? :)

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

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

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

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

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(),

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

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

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: 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 =

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, 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 and a > complex system of

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

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

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

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

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

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

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

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

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

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.

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

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 resolvers are a

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

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: 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

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

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: 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 seems t

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

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

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: 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

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: 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: 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)

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

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 > functional

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

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: 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

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/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: 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

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

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

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

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

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: 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,

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

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

<    1   2   3   4   >