Re: ModelForms
On Nov 7, 2007 10:26 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > ModelForm would be a declarative class that requires, at minimum, a > model attribute. Other attributes would include: > > - formfield_callback (a function that takes a db field and **kwargs > and returns a form field or None) > - fields (a list of field names to include in the form) > - exclude (a list of field names to exclude from the form) I've been +1 on something like this for a long time, as you know :) > The biggest problem I see is that this would be entirely backwards > incompatible with the way form_for_model and form_for_instance work > now. (especially the latter) It *may* be possible to change form_for_X > into some sort of hackish wrappers, but it wouldn't be pretty. I wouldn't lose any sleep if form_for_* died horrible flaming deaths; in fact, I'd show up to toast marshmallows. They're not really powerful enough to do what people want them to do, and so folks end up spending inordinate amounts of time trying to shoehorn extra functionality or customizations into them when (at the moment) the path of least resistance is to just write a form class. I've also felt for a while that the form_for_* helpers don't really "fit" into newforms, because the big win in newforms from the perspective of form authoring is the declarative class style; moving to that style for generated forms would make it feel much more natural to me. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ModelForms
form_for_model and form_for_instance seem like complicated and clever ways to accomplish what basically boils down to a form that has a save method and can accept a model instance in its constructor method. I propose we (or I rather) actually build it that way before 1.0. Form declaration: class MyForm(ModelForm): model = MyModel #optional def save(self, commit=True): # do custom save stuff here if needed Usage: def add_view(request): if request.POST: form = MyForm(request.POST) if form.is_valid() obj = form.save() ... else: form = MyForm() ... def change_view(request, id): obj = MyModel.objects.get(pk=id) if request.POST: form = MyForm(request.POST, obj=obj) if form.is_valid() obj = form.save() ... else: form = MyForm(obj=obj) ... ModelForm would be a declarative class that requires, at minimum, a model attribute. Other attributes would include: - formfield_callback (a function that takes a db field and **kwargs and returns a form field or None) - fields (a list of field names to include in the form) - exclude (a list of field names to exclude from the form) The biggest problem I see is that this would be entirely backwards incompatible with the way form_for_model and form_for_instance work now. (especially the latter) It *may* be possible to change form_for_X into some sort of hackish wrappers, but it wouldn't be pretty. If we don't actually do this, I'll eventually release it as a 3rd party package, but having it around would make some things in newforms-admin a lot more sane to implement. Joseph --~--~-~--~~~---~--~~ 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: ANN: Django sprint, December 1st
Kenneth Gonsalves 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 day! > Until next Saturday. Jonathan. --~--~-~--~~~---~--~~ 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: An addendum to the escaping proposals
Hi, I just switched on the middleware and all my ajax post actions are broken now. I am going to dive in the source and try to figure out how to generate enough token that I can embed in the page on page load, so that all my requests go fine. I would appreciate some tips if someone can tell me if I can reuse the token or I will have to create more than one. Also if the token expire after sometime, that I have to worry about. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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: 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 day! Now you're gonna make me write the whole song. I'll check back in a day or so. :) -Gul --~--~-~--~~~---~--~~ 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: 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 --~--~-~--~~~---~--~~ 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: ANN: Django sprint, December 1st
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 day! -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ 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: ANN: Django sprint, December 1st
On 08-Nov-07, at 2:36 AM, Jacob Kaplan-Moss 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! -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ 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: An addendum to the escaping proposals
On Wed, 2007-11-07 at 19:11 -0600, James Bennett wrote: > On Nov 7, 2007 7:08 PM, James Bennett <[EMAIL PROTECTED]> wrote: > > Which means that this basically boils down to an annoyance attack, > > changing a user's password without their knowledge. But that's already > > exposed to anyone who can guess the user's email address, so anyone > > who simply wants to cause this sort of mischief already has a much > > easier route to accomplish it. > > Sent too soon; I was going to explain that this comes up in the > password reset view, which simply accepts an email address and resets > the account(s) associated with it. The fact that that is also broken (which is very much my view) doesn't the other problem, though. Malcolm -- Quantum mechanics: the dreams stuff is made of. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: An addendum to the escaping proposals
On Nov 7, 2007 7:08 PM, James Bennett <[EMAIL PROTECTED]> wrote: > Which means that this basically boils down to an annoyance attack, > changing a user's password without their knowledge. But that's already > exposed to anyone who can guess the user's email address, so anyone > who simply wants to cause this sort of mischief already has a much > easier route to accomplish it. Sent too soon; I was going to explain that this comes up in the password reset view, which simply accepts an email address and resets the account(s) associated with it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: form_for_instance and form argument, empty form?
On Nov 8, 4:30 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > When you pass in a subclass of Form, it's already got its fields in > the right place, but more importantly, it triggers that syntax > checking again, where it looks for new fields. It basically copies > fields from a parent class, then adds in the fields that it found in > the new class. However, since form_for_model and form_for_instance > don't supply any fields that way, all it gives the new form is what it > found in the parent class, completely overwriting the fields it got > from form_for_*. Actually, I see no good reason why you shouldn't be able to use a Form as the SuperClass of your form_for_* form. I've just attached a patch to #3815 which makes it work. --~--~-~--~~~---~--~~ 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: ANN: Django sprint, December 1st
Hi ppl, I was looking at SprintIdeas on the wiki and did a bit of cleanup at the bottom. I think we could find a more "agile" way to handle the "Results" part of the page, the way it's done now means that when you edit the ticket during the sprint you then have to edit the wiki page to reflect it. But this last step could be avoided, TRAC can insert a TicketQuery just in the middle of a wiki page: [[TicketQuery(status!=closed=sprint)]] For example, would put a list of all tickets not closed with the keyword "sprint". If we place this in the wiki page on Results then contributors would only need to set the keyword "sprint" on the ticket when they update it. And the list on the wiki page would be up-to-date and automagically cleaned up! What do you think? Cheers, Marc El mié, 07-11-2007 a las 14:45 -0600, Jacob Kaplan-Moss escribió: > Howdy folks -- > > We had such a great time doing that last sprint, so we're doing it again! > > We'll hold the sprint Saturday, December 1st here in Lawrence, KS, and > virtually around the world. We'll run things much the same as we did > last time: > > We plan to devote at least 24 hours of focused work to get some of > this done in an organized fashion, and also to encourage new people to > contribute. If all goes well on Saturday, we'll probably continue to > Saturday. > > Anybody can participate and contribute, and there's no obligation or > expectation. If you've never contributed to Django before, this is the > perfect chance for you to chip in. > > More information will be posted shortly at > http://code.djangoproject.com/wiki/Sprint1Dec2007. > > Most participants will likely be working from their own homes/offices > in their respective countries, but if you'd like to come hang out with > us in Lawrence, let me know. We can provide transportation to/from the > Kansas City airport (MCI) and can recommend a good hotel in town. > Also, a limited amount of free lodging (i.e. our couches) is > available. > > All participants -- not just those meeting in person -- should add > their names to the wiki page. > > Help us make this thing as successful as the last one! > > Jacob > > --~--~-~--~~~---~--~~ > 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 > -~--~~~~--~~--~--~--- > signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: An addendum to the escaping proposals
On Wed, 2007-11-07 at 11:08 -0600, James Bennett wrote: > If/when we ever do finally sit down and implement an auto-escaping > proposal, I'd like to suggest we also just go ahead and turn on the > CSRF middleware by default, because apparently the fact that it isn't > enabled by default is leading people to scream about security > vulnerabilities in Django[1], which in turn causes package maintainers > to email me because the existence of a CVE makes it appear that > there's an actual problem here (as opposed to the actual report[2] > which concludes that users should enable the CSRF middleware, and > whose author -- I thought -- concluded that there was no problem after > being pointed in the direction of that middleware). I have quite a different view about the severity of this. Out of the box, Django has a CSRF vulnerability if you use admin. I'm not inclined to dismiss this as a nothing event that you can work around by somehow magically divining that you need to include an optional package if you're using admin. Now, it's very disappointing that the original reported to SecurityFocus didn't report it to us first, but that only makes the original reporter irresponsible and unprofessional, not wrong. I do agree with Chris, though. It's completely unrelated to auto-escaping (which will land today, most likely, since I've been merging it and updating it yesterday and the day before). Not sure if we should build it into admin or make the middleware a requirement for admin, but this isn't a "dismiss it with a wave of the hand" situation for me. > > [1] http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5828 > [2] http://www.securityfocus.com/archive/1/482983/100/0/threaded Regards, Malcolm -- Telepath required. You know where to apply... http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Templates: {% trans %} {% some_tag _() %} and {{ _() }} what gives?
I guess I got a little too excited over this ;-) As for the variable resolution bug, could it be related to this*: http://code.djangoproject.com/ticket/5885 or am I on the wrong track? //D * shameless plug On 11/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-11-07 at 13:01 +, Dmitri Fedortchenko wrote: > > I am trying to figure out the state of the translation tags in the > > django template system. > > > > My ticket has been rejected, but I am not satisfied with the RTFM > > answer given there, based on the claim that python-stuff should not > > work in the template system. > > Using Python as your guide for what should work in the template system > is mistaken. In that respect the ticket responders are correct. The > template system is not Python. The fact that it happens to use some > characters like _() and ".." that are also used in Python is > coincidence. You do have to understand that to make things easier. > > As for the rest, I think there's just been some confusion in the ticket > between what accidentally works and whether it's a good idea or not. > > It is fully intended that _() works in block tags. As an unintended > side-effect it also works in variable resolution tags. Okay, it's > probably not a bad thing. Send in a documentation patch for that. > > Note, however, as was discovered on django-users recently, there is > actually a bug in the way translated portions are parsed in the template > variable parser. I'll fix that when I get a minute. > > The double quotes versus single quotes issue just isn't the big deal > you're making it out to be. Okay, we allow single quotes for string > literals in templates, but it seems that everybody tends to use double > quotes and so they're what get tested mostly. Just use double quotes and > you'll be fine. The above fix to make _() work reliably will probably > fix this, but it's really not worth repeating over and over in your bug > report and the mail you send in. > > Malcolm > > -- > The sooner you fall behind, the more time you'll have to catch up. > http://www.pointy-stick.com/blog/ > > > > > --~--~-~--~~~---~--~~ 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: ANN: Django sprint, December 1st
On 11/7/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > 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 > joking. It's great to hear that there's another sprint. I didn't > expect another one until PyCon in March, so this is good news. D'oh! 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. We *will* certainly be having a sprint after PyCon, of course, so you can start planing for that one now. Of course, the best way to ensure that you're around for the one after that is to hold it in your hometown... Jacob --~--~-~--~~~---~--~~ 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: 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 joking. It's great to hear that there's another sprint. I didn't expect another one until PyCon in March, so this is good news. I'll try to make what I can of it, but I won't add myself to the wiki until I know better what my availability will be. I'd love to get filestorage knocked out if I can, there have been far too many questions about FileField lately (see my latest blog post for all the gory details). Hrm, maybe I can set up an IRC cilent and SVN client over SMS and sit in a corner, coding on my cell phone. Note: another joke, there's no way I could do that. > If all goes well on Saturday, we'll probably continue to Saturday. No comment. -Gul --~--~-~--~~~---~--~~ 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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Interesting, I'll have a look at it after this project is done hehe. I totally understand and am simply throwing ideas around. However it seems that things are already moving in that direction. :) Thanks for the link. //D On 11/7/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > On 11/7/07, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote: > > > > The Admin class should be able to define post_ and pre_save hooks that > are > > called before or after all Manipulation of the model is done (there are > > post_save hooks for the save method, but they are still called before > the > > Manipulator is done working with the model) > > Something similar is in progress already. > http://code.djangoproject.com/wiki/NewformsAdminBranch > > It is however, mostly undocumented and subject to change. These things > take time :) > > Joseph > > > > --~--~-~--~~~---~--~~ 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: ANN: Django sprint, December 1st
On 11/7/07, David Reynolds <[EMAIL PROTECTED]> wrote: > Hurrah! Sprinting in the holiday season! ;) Django bells, Django bells, Django all the way; Oh what fun it is to code In a well-designed dynamic language! [OK, so the last line doesn't scan. Whatever.] Jacob --~--~-~--~~~---~--~~ 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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
On 11/7/07, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote: > > The Admin class should be able to define post_ and pre_save hooks that are > called before or after all Manipulation of the model is done (there are > post_save hooks for the save method, but they are still called before the > Manipulator is done working with the model) Something similar is in progress already. http://code.djangoproject.com/wiki/NewformsAdminBranch It is however, mostly undocumented and subject to change. These things take time :) Joseph --~--~-~--~~~---~--~~ 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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Perhaps. However I believe that customization of the admin is not a bad thing. On the contrary it allows people to use it for most everything that they need without having to write duplicate code... One such thing is the thread_locals hack for created_by/updated_by... Imagine if you wanted to dynamically set the created_by and updated_by fields and were forced to "write a custom view" for every model you have... that basically takes away the usefulness of the admin. Here is an idea: The Admin class should be able to define post_ and pre_save hooks that are called before or after all Manipulation of the model is done (there are post_save hooks for the save method, but they are still called before the Manipulator is done working with the model) On 11/7/07, Collin Grady <[EMAIL PROTECTED]> wrote: > > > Dmitri Fedortchenko said the following: > > Well django does recommend using the admin for everything admin-related, > > if I stop using the admin for editing an article, then I would have to > > write a whole bunch of code just to edit a single article. Suddenly the > > benefit of a unified admin interface is lost and I have to deal with > > permissions, UI, validation, forms.. it seems like a nightmare for > > something should work in the first place... ( i.e. overriding the save() > > method to add extra functionality) > > > > From the django features list: > > A dynamic admin interface: it's not just scaffolding it's the whole > house > > [The philosophy here is that your site is edited by a staff, or a > > client, or maybe just you and you don't want to have to deal with > > creating backend interfaces just to manage content.] > > > > The message seems clear to me. ;) > > It's not meant to do absolutely everything though - trying to hack it to > do something it doesn't is usually harder than writing a really simple > custom view :) > > -- > Collin Grady > > If I had any humility I would be perfect. > -- Ted Turner > > > > > --~--~-~--~~~---~--~~ 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: ANN: Django sprint, December 1st
Jacob Kaplan-Moss wrote: > Howdy folks -- > > We had such a great time doing that last sprint, so we're doing it again! > > We'll hold the sprint Saturday, December 1st here in Lawrence, KS, and > virtually around the world. We'll run things much the same as we did > last time: Hurrah! Sprinting in the holiday season! ;) -- David Reynolds [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Dmitri Fedortchenko said the following: > Well django does recommend using the admin for everything admin-related, > if I stop using the admin for editing an article, then I would have to > write a whole bunch of code just to edit a single article. Suddenly the > benefit of a unified admin interface is lost and I have to deal with > permissions, UI, validation, forms.. it seems like a nightmare for > something should work in the first place... ( i.e. overriding the save() > method to add extra functionality) > > From the django features list: > A dynamic admin interface: it's not just scaffolding it's the whole house > [The philosophy here is that your site is edited by a staff, or a > client, or maybe just you and you don't want to have to deal with > creating backend interfaces just to manage content.] > > The message seems clear to me. ;) It's not meant to do absolutely everything though - trying to hack it to do something it doesn't is usually harder than writing a really simple custom view :) -- Collin Grady If I had any humility I would be perfect. -- Ted Turner --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ANN: Django sprint, December 1st
Howdy folks -- We had such a great time doing that last sprint, so we're doing it again! We'll hold the sprint Saturday, December 1st here in Lawrence, KS, and virtually around the world. We'll run things much the same as we did last time: We plan to devote at least 24 hours of focused work to get some of this done in an organized fashion, and also to encourage new people to contribute. If all goes well on Saturday, we'll probably continue to Saturday. Anybody can participate and contribute, and there's no obligation or expectation. If you've never contributed to Django before, this is the perfect chance for you to chip in. More information will be posted shortly at http://code.djangoproject.com/wiki/Sprint1Dec2007. Most participants will likely be working from their own homes/offices in their respective countries, but if you'd like to come hang out with us in Lawrence, let me know. We can provide transportation to/from the Kansas City airport (MCI) and can recommend a good hotel in town. Also, a limited amount of free lodging (i.e. our couches) is available. All participants -- not just those meeting in person -- should add their names to the wiki page. Help us make this thing as successful as the last one! Jacob --~--~-~--~~~---~--~~ 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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Well django does recommend using the admin for everything admin-related, if I stop using the admin for editing an article, then I would have to write a whole bunch of code just to edit a single article. Suddenly the benefit of a unified admin interface is lost and I have to deal with permissions, UI, validation, forms.. it seems like a nightmare for something should work in the first place... (i.e. overriding the save() method to add extra functionality) From the django features list: A dynamic admin interface: it's not just scaffolding it's the whole house [The philosophy here is that your site is edited by a staff, or a client, or maybe just you and you don't want to have to deal with creating backend interfaces just to manage content.] The message seems clear to me. ;) //D On 11/7/07, Collin Grady <[EMAIL PROTECTED]> wrote: > > > Dmitri Fedortchenko said the following: > > Still, the most logical course is to override the save method. > > I'd say the more logical course is to stop using admin for this ;) > > -- > Collin Grady > > QOTD: > "If I'm what I eat, I'm a chocolate chip cookie." > > > > --~--~-~--~~~---~--~~ 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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Dmitri Fedortchenko said the following: > Still, the most logical course is to override the save method. I'd say the more logical course is to stop using admin for this ;) -- Collin Grady QOTD: "If I'm what I eat, I'm a chocolate chip cookie." --~--~-~--~~~---~--~~ 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: form_for_instance and form argument, empty form?
Marty Alchin a écrit :
>>> 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)
with an instance of foo which only contains a basic field (let's say a
CharField) and FooForm with a unique field too, the input rendered will
not be completed with the content of the foo instance. If you remove the
form argument:
forms.form_for_instance(foo)
the generated form contains the content of the foo instance.
I'd tried to find the bug but this line (122 of newforms.models):
return type(opts.object_name + 'InstanceForm', (form,),
{'base_fields': base_fields, '_model': model,
'save': make_instance_save(instance, fields, 'changed')})
give me headaches ;-). The only thing I can say is that base_fields
contains the initial data before this line but my returned form not.
Did somebody use this argument and can confirm?
>
> I can confirm that it does in fact work as you describe, but I don't
> believe it's a bug. The only documentation I was able to find on this
> argument is in the docstrings for form_for_model and
> form_for_instance, both of which clearly state that it's intended to
> receive a subclass of BaseForm, not Form.
>
You're absolutely right on that point. I just found it in the
documentation too:
http://www.djangoproject.com/documentation/models/model_forms/
> Here's the difference.
>
> BaseForm is what provides all the real functionality for the form:
> iterating over fields, triggering HTML output, managing validation,
> etc. It's not normally used outside of Django's internals, because the
> Form class subclasses it already. However, it doesn't know anything
> about how to get the fields for the form. Instead, the Form class uses
> a special way to pull fields out of the class definition and assign
> them where they belong. form_for_model and form_for_instance don't
> need this syntax, so they bypass that step by directly assigning the
> fields where they belong when they create the class.
>
> When you pass in a subclass of Form, it's already got its fields in
> the right place, but more importantly, it triggers that syntax
> checking again, where it looks for new fields. It basically copies
> fields from a parent class, then adds in the fields that it found in
> the new class. However, since form_for_model and form_for_instance
> don't supply any fields that way, all it gives the new form is what it
> found in the parent class, completely overwriting the fields it got
> from form_for_*.
>
> That was a bit of a long explanation, but I think it's necessary to
> know what's going on, and it leaves me with two more points.
>
> As for what that form argument was meant for, it's designed for a
> BaseForm subclass. This allows you to add *methods* to your generated
> form, not new fields.
>
> As for what you're trying to do, check out the 'fields' argument to
> form_for_instance. It creates a form with just a subset of the fields
> from the original model.
>
Wow, thanks for this interesting explanation! I always wondered what's
the difference between Form and BaseForm without digging too deep into
the code. Now that's really clear.
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 more natural to me instead of dealing with
fields, form and eventually form_for_fields... I know that those
functions are just shortcuts but it works very well in terms of
genericity and my main concern here is to integrate a generic way to
handle forms for resources in restapi.
If you have any suggestion about that I'll be very happy to learn a bit
more :)
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
An addendum to the escaping proposals
If/when we ever do finally sit down and implement an auto-escaping proposal, I'd like to suggest we also just go ahead and turn on the CSRF middleware by default, because apparently the fact that it isn't enabled by default is leading people to scream about security vulnerabilities in Django[1], which in turn causes package maintainers to email me because the existence of a CVE makes it appear that there's an actual problem here (as opposed to the actual report[2] which concludes that users should enable the CSRF middleware, and whose author -- I thought -- concluded that there was no problem after being pointed in the direction of that middleware). [1] http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5828 [2] http://www.securityfocus.com/archive/1/482983/100/0/threaded -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: 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)
> >>
> >> with an instance of foo which only contains a basic field (let's say a
> >> CharField) and FooForm with a unique field too, the input rendered will
> >> not be completed with the content of the foo instance. If you remove the
> >> form argument:
> >>
> >> forms.form_for_instance(foo)
> >>
> >> the generated form contains the content of the foo instance.
> >>
> >> I'd tried to find the bug but this line (122 of newforms.models):
> >>
> >> return type(opts.object_name + 'InstanceForm', (form,),
> >> {'base_fields': base_fields, '_model': model,
> >> 'save': make_instance_save(instance, fields, 'changed')})
> >>
> >> give me headaches ;-). The only thing I can say is that base_fields
> >> contains the initial data before this line but my returned form not.
> >>
> >> Did somebody use this argument and can confirm?
I can confirm that it does in fact work as you describe, but I don't
believe it's a bug. The only documentation I was able to find on this
argument is in the docstrings for form_for_model and
form_for_instance, both of which clearly state that it's intended to
receive a subclass of BaseForm, not Form.
Here's the difference.
BaseForm is what provides all the real functionality for the form:
iterating over fields, triggering HTML output, managing validation,
etc. It's not normally used outside of Django's internals, because the
Form class subclasses it already. However, it doesn't know anything
about how to get the fields for the form. Instead, the Form class uses
a special way to pull fields out of the class definition and assign
them where they belong. form_for_model and form_for_instance don't
need this syntax, so they bypass that step by directly assigning the
fields where they belong when they create the class.
When you pass in a subclass of Form, it's already got its fields in
the right place, but more importantly, it triggers that syntax
checking again, where it looks for new fields. It basically copies
fields from a parent class, then adds in the fields that it found in
the new class. However, since form_for_model and form_for_instance
don't supply any fields that way, all it gives the new form is what it
found in the parent class, completely overwriting the fields it got
from form_for_*.
That was a bit of a long explanation, but I think it's necessary to
know what's going on, and it leaves me with two more points.
As for what that form argument was meant for, it's designed for a
BaseForm subclass. This allows you to add *methods* to your generated
form, not new fields.
As for what you're trying to do, check out the 'fields' argument to
form_for_instance. It creates a form with just a subset of the fields
from the original model.
-Gul
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Earn Money Online! No Registration Fees. Guaranteed Payments.
http://www.moneycosmos.com/?r=321740 --~--~-~--~~~---~--~~ 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: Help with loader error
Gary, To mix metaphors, sometimes it takes a second pair of eyes to make the lightbulb go off. I'm not sure how that got in there but I had already deleted several instances of "untitled folder" from the file. I just didn't recognize the name in the error code. Thanks. Charles From: django-developers@googlegroups.com on behalf of Gary Wilson Sent: Tue 11/6/2007 7:42 PM To: django-developers@googlegroups.com Subject: Re: Help with loader error Charles wrote: > I've installed Django v.0.96 on an Ubuntu Linux 7.10 system and am > going through the tutorial available at the Django site. The latest > error popped up when I tried to run the admin app. The current error > is: > > ImproperlyConfigured at /admin/ > Module "django.template.loaders.filesystem" does not define a > "load_template_souuntitled folderrce" callable template source loader It appears that an inadvertent "untitled folder" string got pasted into your settings.py file for the TEMPLATE_LOADERS setting. Gary --~--~-~--~~~---~--~~ 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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
That is what I thought as well, however I checked, and the _add_items() method is only called once with the correct objects (meaning the existing keywords and the keywords that I added). Are you telling me that the admin actually has it's own method for setting the relationships that is outside the django.models.fields.related module? //Dmitri On Nov 7, 2:02 am, Collin Grady <[EMAIL PROTECTED]> wrote: > Are you seeing this behavior in admin? If so, I believe that is what is > actually at fault, since it hard-sets m2ms, which would clear anything > set in save(). > > Also, you don't need to call save() again after adding to an m2m, since > it does not edit the model instance itself, but the related table. > > -- > Collin Grady > > Haste makes waste. > -- John Heywood --~--~-~--~~~---~--~~ 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: 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]> 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)
>
> with an instance of foo which only contains a basic field (let's say a
> CharField) and FooForm with a unique field too, the input rendered will
> not be completed with the content of the foo instance. If you remove the
> form argument:
>
> forms.form_for_instance(foo)
>
> the generated form contains the content of the foo instance.
>
> I'd tried to find the bug but this line (122 of newforms.models):
>
> return type(opts.object_name + 'InstanceForm', (form,),
> {'base_fields': base_fields, '_model': model,
> 'save': make_instance_save(instance, fields, 'changed')})
>
> give me headaches ;-). The only thing I can say is that base_fields
> contains the initial data before this line but my returned form not.
>
> Did somebody use this argument and can confirm?
>
> Regards,
> David
>
>
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
form_for_instance and form argument, empty form?
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)
with an instance of foo which only contains a basic field (let's say a
CharField) and FooForm with a unique field too, the input rendered will
not be completed with the content of the foo instance. If you remove the
form argument:
forms.form_for_instance(foo)
the generated form contains the content of the foo instance.
I'd tried to find the bug but this line (122 of newforms.models):
return type(opts.object_name + 'InstanceForm', (form,),
{'base_fields': base_fields, '_model': model,
'save': make_instance_save(instance, fields, 'changed')})
give me headaches ;-). The only thing I can say is that base_fields
contains the initial data before this line but my returned form not.
Did somebody use this argument and can confirm?
Regards,
David
--~--~-~--~~~---~--~~
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: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Hi
Basically I have followed the call all the way to the execution of the
cursor.execute() on line 343 in models.fields.related.
I have not actually delved into the transaction method. However in my
setup I am using the django admin, I have not set up any automatic
transaction handling and the save method does is not transaction
managed. Also I am running this on an existing object, and even if I
was not, the primary key would have been created since the save method
is called before I add new m2ms.
Calling the super(Chapter,self).save() AFTER adding new m2ms is not
needed, nor does it work.
I also checked to make sure that the
django.models.fields.related._remove_items() method is not called
after the _add_items() method, to restore some previous state.
My only conclusion is that somehow the transaction of the save()
cancels out the transaction of the _add_items() method...
Maybe it's the
save.alters_data = True
flag?
or something to do with the dispatcher? I have not yet gone that deep
into the source...
But I can assure you that I am using as basic a setup as possible.
It is simply django admin, MySQL with InnoDB and that very save method
that you see in my initial post.
So repeating this should not be a problem...
I'll try to delve deeper into the transaction side of things, but any
insight you can give me would be appreciated.
//Dmitri
On Nov 7, 2:25 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-11-07 at 00:50 +, Dmitri Fedortchenko wrote:
> > Example code:
>
> > def save(self):
> >regex = re.compile("\{\{([^\}]{2,60})\}\}")
> >words = regex.findall(self.body)
> >self.body = regex.sub("\\1",self.body)
> >super(Chapter,self).save()
> >for word in words:
> >if len(word.strip()) > 0:
> >try:
> >self.keywords.create(value=word.strip().title())
> >except Exception, e:
> >print e
> >print self.keywords.all() # This prints the correct keywords!
> >super(Chapter,self).save()
>
> > The outcome of this code is that new Keywords are created, but they
> > are not bound to this Chapter.
> > Simply calling chapter.keywords.create(value="Test") will indeed
> > create a new keyword with the value "Test" bound to the chapter. I am
> > running this from the django admin btw.
>
> Can you explain what is meant to be going on here?
>
> If you are trying to save m2m relations for an object that has not been
> saved yet, you're out of luck. We need to know the current object's pk
> value before it can be used in a m2m table and that isn't always
> available (with auto primary keys).
>
> Normally, if you want to adjust the m2m relations for a model, hooking
> into the post_save signal is the way to go.
>
>
>
> > The problem seems to be in the
> > django.db.models.fields.related._add_items method, somewhere around
> > line 340.
> > The fact is that the insertion query is executed, but for some reason
> > it is not committed, perhaps it is a transaction issue?
>
> Perhaps it is. Perhaps it isn't. How have you established the query was
> executed? What does the commit_unless_managed() call end up doing in
> your case? It might depend on your particular setup, too. Do some more
> debugging and see what shows up if you think there's a problem there.
> However, do keep in mind that it's generally impossible to do everything
> with m2m's inside a model's save method because of the chicken-and-egg
> problem with primary keys noted above.
>
> Regards,
> Malcolm
>
> --
> Tolkien is hobbit-forming.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
