Re: Lets talk about a dynamic limit_choices_to again :)
I totally agree, I think it was a great idea and I am glad to help in implementing it! William: if you don't have edit_inline objects that need this functionality, you should try my patch. I'd love to hear some feedback! :) It makes it super easy to do something that no admin can be without: IE the ability to limit selections based on the currently open object. Like if you are editing a user from a certain country, you should only be able to assign a city to that user which is bound to the user's country etc. I've always missed that functionality in django, and now it's here with a minimum of fuss. However... I've spent the last few days trying to get this working together with edit_inline. Unfortunately, that code is quite complicated. I could even call it a mess, but it might just be my own incompetence. The model code is deeply intertwined with oldforms code and the line between them is often very blurry. I am guessing there is work going on in that area. I think I am close to getting it working with edit_inline, it may involve a hack or two, but hopefully it can be done. I'll post more once I have something. If anyone who is more familiar with edit_inline code has some suggestions, please chime in :) //Dmitri On Nov 25, 2007 7:04 PM, William Waites <[EMAIL PROTECTED]> wrote: > > On Fri, Nov 23, 2007 at 02:05:28PM -0800, Dmitri Fedortchenko wrote: > > > > I found this ticket: > > http://code.djangoproject.com/ticket/2445 > > > > It's not seen much activity for a while, but in september jkocherhans > > posted some news which I found interesting. So since I needed this > > functionality, I wrote a patch for it. > > > > Basically the idea is that you can define: > > def choices_for__FIELD(self): > > return ModelClass.objects.filter(relation_name=self.relation) > > This looks like quite a clean way to accomplish dynamic choices. I've > needed things like this as well and often have resorted to rather less > elegant hacks. > > Any chance of getting this or something similar pulled into the trunk? > > Cheers, > -w > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Lets talk about a dynamic limit_choices_to again :)
I found this ticket: http://code.djangoproject.com/ticket/2445 It's not seen much activity for a while, but in september jkocherhans posted some news which I found interesting. So since I needed this functionality, I wrote a patch for it. The patch is still shaky on edit_inline objects, but it works for normal models. I'm working on getting it to work on edit_inlines too (somehow hehe). Basically the idea is that you can define: def choices_for__FIELD(self): return ModelClass.objects.filter(relation_name=self.relation) This function will be called when it is time to display or otherwise fetch the choices for this particular row. The patch also allows you to use normal QuerySets with the choices= attribute for a any field (so you don't need to use the function if the choices are more or less static). Basically this eliminates the need for limit_choices_to alltogether and allows for much more advanced functionality for the admin and model-based forms. The nice part is that the patch is perhaps 10 lines of code, and does not break any existing model definitions. --~--~-~--~~~---~--~~ 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: Using filters with {% trans %} tag
I killed a few birds with one stone.
This patch turned out to be even more interesting then I thought.
As I was working on it I found a really neat way to move even more of
the implementation out from the templatetag itself and into the
template processor. Check it out:
http://code.djangoproject.com/ticket/5972
This is the patch to fix FilterExpression's treatment of escaped
quotes:
http://code.djangoproject.com/ticket/5980
I've now been using these patches on my own django projects and they
feel solid.
However if someone was relying on the lack of escape processing in
FilterExpression for some strange hacks, then they may have some
issues.
//D
On Nov 18, 4:41 pm, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote:
> I found something.
>
> FilterExpression seems to be a bad boy.
>
> Check out these two pieces of code (in the __init__ function of
> FilterExpression):
> if i18n_constant:
> var = "'%s'" % _(i18n_constant)
> elif constant:
> var = "'%s'" % constant
> ==
> if i18n_arg:
> args.append((False, _(i18n_arg.replace(r'\"',
> '"'
> elif constant_arg is not None:
> args.append((False, constant_arg.replace(r'\"',
> '"')))
>
> One fixes escaped strings, the other does not. This is inconsistent.
> Picture:
>
> {{ _("This is an \"object\"")|filter:"Some\"thing\"" }}
>
> This will be parsed ok, but the translation will fail.
> Adding replace('\"','"') to the "constant" in the first piece of code
> will solve this little problem and it seems only fair that you should
> be able to escape doublequotes (since it's clearly possible in filter
> arguments)...
>
> Should I start a new ticket for this or bake it into the "backwards
> compatibility fix" of my i18n templatetag
> patchhttp://code.djangoproject.com/ticket/5972
> ?
>
> On Nov 18, 7:43 am, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote:
>
> > Ok I put it up.
>
> > It does not affect the _() syntax at all, except for allowing the use
> > of _() within a trans tag... But I don't feel that it is a problem.
>
> > The patch includes a backwards-compatiblity workaround. Again I bring
> > up the single/double quote issue, but since {% trans %} works with
> > single quotes and FilterExpression does not, I had to add a few lines
> > of code to fix strings surrounded with single quotes so they would be
> > surrounded with doubles instead :)
>
> > There are still some issues around that actually, for example if the
> > user has something like this:
>
> > {% trans 'Please select an "object"' %}
>
> > It will be broken with the new patch since the single quotes will be
> > replaced with doubles. I am working on some ideas on how to combat
> > this since simply escaping the quotes with two \\ does do the trick
> > because FilterExpression interprets them literally...
>
> > Now it's time for bed.
>
> > //D
>
> > On Nov 18, 4:09 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Sat, 2007-11-17 at 17:47 -0800, Dmitri Fedortchenko wrote:
> > > > Once again I return with my whacky ideas.
>
> > > > I want to apply filters to my translations in the templates. So.
> > > > I have created a patch which allows use of the following syntax:
>
> > > > {% trans "username"|capfirst|slice:"2:" noop %}
> > > > {% trans somevar|slice:"2:" %}
>
> > > > The filters are applied on the result of the translation, and not the
> > > > translation id string.
>
> > > > While this is already possible by using the {{ _("username")|filter }}
> > > > syntax, I think that {% trans %} is more "django-ish" and looks nicer
> > > > too...
>
> > > > Does anyone think this is useful?
>
> > > +1 from me, providing it doesn't break the existing usage with _().
> > > Create a ticket and attach the patch.
>
> > > 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: Using filters with {% trans %} tag
I found something.
FilterExpression seems to be a bad boy.
Check out these two pieces of code (in the __init__ function of
FilterExpression):
if i18n_constant:
var = "'%s'" % _(i18n_constant)
elif constant:
var = "'%s'" % constant
==
if i18n_arg:
args.append((False, _(i18n_arg.replace(r'\"',
'"'
elif constant_arg is not None:
args.append((False, constant_arg.replace(r'\"',
'"')))
One fixes escaped strings, the other does not. This is inconsistent.
Picture:
{{ _("This is an \"object\"")|filter:"Some\"thing\"" }}
This will be parsed ok, but the translation will fail.
Adding replace('\"','"') to the "constant" in the first piece of code
will solve this little problem and it seems only fair that you should
be able to escape doublequotes (since it's clearly possible in filter
arguments)...
Should I start a new ticket for this or bake it into the "backwards
compatibility fix" of my i18n templatetag patch
http://code.djangoproject.com/ticket/5972
?
On Nov 18, 7:43 am, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote:
> Ok I put it up.
>
> It does not affect the _() syntax at all, except for allowing the use
> of _() within a trans tag... But I don't feel that it is a problem.
>
> The patch includes a backwards-compatiblity workaround. Again I bring
> up the single/double quote issue, but since {% trans %} works with
> single quotes and FilterExpression does not, I had to add a few lines
> of code to fix strings surrounded with single quotes so they would be
> surrounded with doubles instead :)
>
> There are still some issues around that actually, for example if the
> user has something like this:
>
> {% trans 'Please select an "object"' %}
>
> It will be broken with the new patch since the single quotes will be
> replaced with doubles. I am working on some ideas on how to combat
> this since simply escaping the quotes with two \\ does do the trick
> because FilterExpression interprets them literally...
>
> Now it's time for bed.
>
> //D
>
> On Nov 18, 4:09 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > On Sat, 2007-11-17 at 17:47 -0800, Dmitri Fedortchenko wrote:
> > > Once again I return with my whacky ideas.
>
> > > I want to apply filters to my translations in the templates. So.
> > > I have created a patch which allows use of the following syntax:
>
> > > {% trans "username"|capfirst|slice:"2:" noop %}
> > > {% trans somevar|slice:"2:" %}
>
> > > The filters are applied on the result of the translation, and not the
> > > translation id string.
>
> > > While this is already possible by using the {{ _("username")|filter }}
> > > syntax, I think that {% trans %} is more "django-ish" and looks nicer
> > > too...
>
> > > Does anyone think this is useful?
>
> > +1 from me, providing it doesn't break the existing usage with _().
> > Create a ticket and attach the patch.
>
> > 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: Using filters with {% trans %} tag
Ok I put it up.
It does not affect the _() syntax at all, except for allowing the use
of _() within a trans tag... But I don't feel that it is a problem.
The patch includes a backwards-compatiblity workaround. Again I bring
up the single/double quote issue, but since {% trans %} works with
single quotes and FilterExpression does not, I had to add a few lines
of code to fix strings surrounded with single quotes so they would be
surrounded with doubles instead :)
There are still some issues around that actually, for example if the
user has something like this:
{% trans 'Please select an "object"' %}
It will be broken with the new patch since the single quotes will be
replaced with doubles. I am working on some ideas on how to combat
this since simply escaping the quotes with two \\ does do the trick
because FilterExpression interprets them literally...
Now it's time for bed.
//D
On Nov 18, 4:09 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2007-11-17 at 17:47 -0800, Dmitri Fedortchenko wrote:
> > Once again I return with my whacky ideas.
>
> > I want to apply filters to my translations in the templates. So.
> > I have created a patch which allows use of the following syntax:
>
> > {% trans "username"|capfirst|slice:"2:" noop %}
> > {% trans somevar|slice:"2:" %}
>
> > The filters are applied on the result of the translation, and not the
> > translation id string.
>
> > While this is already possible by using the {{ _("username")|filter }}
> > syntax, I think that {% trans %} is more "django-ish" and looks nicer
> > too...
>
> > Does anyone think this is useful?
>
> +1 from me, providing it doesn't break the existing usage with _().
> Create a ticket and attach the patch.
>
> 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: django.template.TokenParser inconsistent when it comes to filters...
Great.
Here are the tickets:
http://code.djangoproject.com/ticket/5971
http://code.djangoproject.com/ticket/5972
And while we're on the subject of tickets:
I've been digging around in the jungle of template parsing while
working on this patch and and the trans patch, and a thought occured
to me.
Why can't the Variable class handle processing of filters instead of
FilterExpression.resolve?
A Variable in a template is either a literal or a variable from the
context, and those can in most cases have filters applied to them.
Wouldn't it be nice if a Variable would simply have a "filters" list
and the resolve method would be the one doing the application of said
filters? (with the option to simply NOT apply the filters)
Obviously it's a pretty daring idea and I don't have much to back it
up right now, but my thought is that there seems to be way too many
steps involved in parsing a single token and there are many datatypes;
hard to keep track of everything.
If we look at it in the scope of tags and {{}} (what would I call
that?), then they can basically contain only a few datatypes:
literals, context variables, filters and parameters.
So why not make it a little more "defined" and give Variables the
power they deserve! ;)
It's 5am, so my thoughts are not coming out clearly. But if the above
makes you think "hmm, interesting", I can write up something more
detailed, maybe with some code examples...
//Dmitri
On Nov 18, 4:08 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2007-11-17 at 18:27 -0800, Dmitri Fedortchenko wrote:
> > The django.template.TokenParser has a little problem.
>
> > I am not sure if this is a problem actually, but it is inconsistent
> > when parsing filters that follow constant strings or variables.
>
> > Meaning that:
> > {% tag thevar|filter sometag %} will produce:
> > self.value() = "thevar|filter"
> > self.tag() = "sometag"
>
> > However:
> > {% tag "a value"|filter sometag %} will produce:
> > self.value() = "a value"
> > self.tag() = "|filter"
> > self.tag() = "sometag"
>
> > This does not seem like correct behaviour...
> > I made a very simple patch for this, thus the outcome of the above:
>
> > {% tag "a value"|filter sometag %} will produce:
> > value = "a value"|filter
> > tag = sometag
>
> I think this is probably the right idea, yes. TokenParser is a bit of an
> odd duck. Nothing in core uses it except the i18n template tags, so it
> hasn't gotten as much attention during the recent Variable refactoring.
> When I do work in the i18n template tags I realise that the API of
> TokenParser really isn't particularly handy (it kind of cries out for an
> iterator, for example). Fortunately, most changes can be made
> incrementally and without backwards incompatibilities.
>
> I've kind of been holding off on doing much work here since it currently
> "mostly works" and Tom Tobin had some good ideas about making template
> tag creation a bit easier. I've been hoping to work with him at some
> point to get that polished up and into trunk. One of the places it would
> help simplify is django.templatetags.i18n.
>
> For now, I'd be happy if you'd create a ticket with your patch to make
> the above change. It's slightly backwards incompatible, but not in a
> hard-to-fix way for downstream developers (normally, the result of any
> such expression is going to be passed to compile_filter() anyway and
> this makes that easier).
>
> Regards,
> Malcolm
>
> --
> Remember that you are unique. Just like everyone
> else.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
-~--~~~~--~~--~--~---
django.template.TokenParser inconsistent when it comes to filters...
The django.template.TokenParser has a little problem.
I am not sure if this is a problem actually, but it is inconsistent
when parsing filters that follow constant strings or variables.
Meaning that:
{% tag thevar|filter sometag %} will produce:
self.value() = "thevar|filter"
self.tag() = "sometag"
However:
{% tag "a value"|filter sometag %} will produce:
self.value() = "a value"
self.tag() = "|filter"
self.tag() = "sometag"
This does not seem like correct behaviour...
I made a very simple patch for this, thus the outcome of the above:
{% tag "a value"|filter sometag %} will produce:
value = "a value"|filter
tag = sometag
So now we can simply pass the "value" into a FilterExpression to parse
the filters...
Am I on the wrong track here?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Using filters with {% trans %} tag
Once again I return with my whacky ideas.
I want to apply filters to my translations in the templates. So.
I have created a patch which allows use of the following syntax:
{% trans "username"|capfirst|slice:"2:" noop %}
{% trans somevar|slice:"2:" %}
The filters are applied on the result of the translation, and not the
translation id string.
While this is already possible by using the {{ _("username")|filter }}
syntax, I think that {% trans %} is more "django-ish" and looks nicer
too...
Does anyone think this is useful?
PS: the patch is not too complicated, it replaces about 10 lines of
code and adds 10 extra. but the results are magnificent! ;-)
--~--~-~--~~~---~--~~
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: 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: 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: 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
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: 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 +0000, 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
-~--~~~~--~~--~--~---
Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
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.
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?
It is simply broken when called from within the save() method of a
Model instance...
I haven't started a ticket because I am not sure if this is bug or a
feature ;-)
--~--~-~--~~~---~--~~
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: Stripping spaces and linebreaks from blocktrans?
Sounds good. I'll try to clean up the patch as much as possible when I get some time too. Right now it's a little rough around the edges. //D On 11/1/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-10-31 at 19:17 +0100, Dmitri Fedortchenko wrote: > > I opened a ticket, looking forward to your input and ideas. > > > > http://code.djangoproject.com/ticket/5849 > > Thanks. I'll get to it eventually, but it might take a week or so. I'm > pretty busy right at the moment and have a few other Django commitments > to deliver on. At some point I have to spend a few days closing all the > internationalisation bugs, though. I'd like to that sometime in > November. > > Regards, > Malcolm > > -- > I just got lost in thought. It was unfamiliar territory. > 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: Stripping spaces and linebreaks from blocktrans?
I opened a ticket, looking forward to your input and ideas.
http://code.djangoproject.com/ticket/5849
On 10/31/07, Dmitri Fedortchenko <[EMAIL PROTECTED]> wrote:
>
> Now that I re-read your definition, there is one difference between your
> suggestion and my patch.
> My patch just uses the first line to define the amount of whitespace to
> strip, while you suggest we use the shortest indentation in the whole block.
>
>
> Which is better?
>
> //D
>
> On 10/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Sun, 2007-10-28 at 21:46 +, Dmitri Fedortchenko wrote:
> > > That's a great idea! I'll see if I can squeeze out a patch for this,
> > > since I feel that I want to be able to indent blocktrans without
> > > having the extra spaces in the po files (I realize one can remove the
> > > extra spaces manually in the po files, but I like consistent
> > > autogeneration hehe).
> > >
> > > In other words, whitespace equal to the amount of the indentation of
> > > first line will be removed, as well as leading and trailing whitespace
> > > and line breaks.
> > > One question that springs to mind: If the first line is on the same
> > > line as the {% blocktrans %}tag itself (i.e. it has no indentation),
> > > should we strip the subsequent lines based on the indentation of the
> > > second line, or assume that the user wants to keep the text as is?
> >
> > Well, firstly, I'd rather you solved the two problems in a slightly
> > reverse order: first allow linebreaks inside blocktrans, then let's
> > worry about stripping whitespace. But it's up to you.
> >
> > My ideal scenario would be that if we have a block of text that needs to
> > be translated, strip a constant amount of whitespace from the front of
> > each line. This amount will be the minimum amount of leading whitespace
> > on any of the lines in that block. So, at the end, one line (at least)
> > will always be flush against the left margin and all other lines will be
> > indented relative to that line as they were in the source text.
> >
> > (My reason for writing that alternative formulation is because I don't
> > really understand what you were asking about being on the same level as
> > the blocktrans tag. I'm not sure why the tag is relevant here.)
> >
> > Come up with a patch that does whatever you like and we can go from
> > there. I think we're thinking along similar lines, so it will be easy
> > enough to tweak once we have some concrete code to throw darts at.
> >
> > Regards,
> > Malcolm
> >
> > --
> > Remember that you are unique. Just like everyone else.
> > 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: Stripping spaces and linebreaks from blocktrans?
Now that I re-read your definition, there is one difference between your
suggestion and my patch.
My patch just uses the first line to define the amount of whitespace to
strip, while you suggest we use the shortest indentation in the whole block.
Which is better?
//D
On 10/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 2007-10-28 at 21:46 +, Dmitri Fedortchenko wrote:
> > That's a great idea! I'll see if I can squeeze out a patch for this,
> > since I feel that I want to be able to indent blocktrans without
> > having the extra spaces in the po files (I realize one can remove the
> > extra spaces manually in the po files, but I like consistent
> > autogeneration hehe).
> >
> > In other words, whitespace equal to the amount of the indentation of
> > first line will be removed, as well as leading and trailing whitespace
> > and line breaks.
> > One question that springs to mind: If the first line is on the same
> > line as the {% blocktrans %}tag itself (i.e. it has no indentation),
> > should we strip the subsequent lines based on the indentation of the
> > second line, or assume that the user wants to keep the text as is?
>
> Well, firstly, I'd rather you solved the two problems in a slightly
> reverse order: first allow linebreaks inside blocktrans, then let's
> worry about stripping whitespace. But it's up to you.
>
> My ideal scenario would be that if we have a block of text that needs to
> be translated, strip a constant amount of whitespace from the front of
> each line. This amount will be the minimum amount of leading whitespace
> on any of the lines in that block. So, at the end, one line (at least)
> will always be flush against the left margin and all other lines will be
> indented relative to that line as they were in the source text.
>
> (My reason for writing that alternative formulation is because I don't
> really understand what you were asking about being on the same level as
> the blocktrans tag. I'm not sure why the tag is relevant here.)
>
> Come up with a patch that does whatever you like and we can go from
> there. I think we're thinking along similar lines, so it will be easy
> enough to tweak once we have some concrete code to throw darts at.
>
> Regards,
> Malcolm
>
> --
> Remember that you are unique. Just like everyone else.
> 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: Stripping spaces and linebreaks from blocktrans?
Ok I got the patch.
Should I open a ticket?
I attached it, but not sure if it will get through to the mailing list.
I also attached a semi-comprehensive battery of tests, showing the outcome
of the stripping process.
Basically it strips indentation based on the indentation of the first line
of text.
If the first line is empty, it will use the indentation of the second line.
If the first line has no indentation, then nothing other then a .strip()
will be done to the string.
If any subsequent lines have less indentation then the first line, then
those lines will be de-indented as much as possible.
If any subsequent lines have more indetation then the first line, then only
the amount of indetation equal to the first line is stripped.
The only caveat is if mixed tabs and spaces are used for indentation, some
strange results may be produced.
//D
On 10/29/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 2007-10-28 at 21:46 +, Dmitri Fedortchenko wrote:
> > That's a great idea! I'll see if I can squeeze out a patch for this,
> > since I feel that I want to be able to indent blocktrans without
> > having the extra spaces in the po files (I realize one can remove the
> > extra spaces manually in the po files, but I like consistent
> > autogeneration hehe).
> >
> > In other words, whitespace equal to the amount of the indentation of
> > first line will be removed, as well as leading and trailing whitespace
> > and line breaks.
> > One question that springs to mind: If the first line is on the same
> > line as the {% blocktrans %}tag itself (i.e. it has no indentation),
> > should we strip the subsequent lines based on the indentation of the
> > second line, or assume that the user wants to keep the text as is?
>
> Well, firstly, I'd rather you solved the two problems in a slightly
> reverse order: first allow linebreaks inside blocktrans, then let's
> worry about stripping whitespace. But it's up to you.
>
> My ideal scenario would be that if we have a block of text that needs to
> be translated, strip a constant amount of whitespace from the front of
> each line. This amount will be the minimum amount of leading whitespace
> on any of the lines in that block. So, at the end, one line (at least)
> will always be flush against the left margin and all other lines will be
> indented relative to that line as they were in the source text.
>
> (My reason for writing that alternative formulation is because I don't
> really understand what you were asking about being on the same level as
> the blocktrans tag. I'm not sure why the tag is relevant here.)
>
> Come up with a patch that does whatever you like and we can go from
> there. I think we're thinking along similar lines, so it will be easy
> enough to tweak once we have some concrete code to throw darts at.
>
> Regards,
> Malcolm
>
> --
> Remember that you are unique. Just like everyone else.
> 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
-~--~~~~--~~--~--~---
Index: django/utils/translation/trans_real.py
===
--- django/utils/translation/trans_real.py (revision 6635)
+++ django/utils/translation/trans_real.py (working copy)
@@ -443,20 +443,26 @@
inplural = False
singular = []
plural = []
+
+from django.utils.translation import strip_blocktrans
+
for t in Lexer(src, None).tokenize():
if intrans:
if t.token_type == TOKEN_BLOCK:
endbmatch = endblock_re.match(t.contents)
pluralmatch = plural_re.match(t.contents)
if endbmatch:
+singular = strip_blocktrans(''.join(singular))
+
if inplural:
-out.write(' ngettext(%r,%r,count) ' % (''.join(singular), ''.join(plural)))
+plural = strip_blocktrans(''.join(plural))
+out.write(' ngettext(%r,%r,count) ' % (singular, plural))
for part in singular:
out.write(blankout(part, 'S'))
for part in plural:
out.write(blankout(part, 'P'))
else:
-out.write(' gettext(%r) ' % ''.join(singular))
+out.write(' gettext(%r) ' % s
Re: Stripping spaces and linebreaks from blocktrans?
That's a great idea! I'll see if I can squeeze out a patch for this,
since I feel that I want to be able to indent blocktrans without
having the extra spaces in the po files (I realize one can remove the
extra spaces manually in the po files, but I like consistent
autogeneration hehe).
In other words, whitespace equal to the amount of the indentation of
first line will be removed, as well as leading and trailing whitespace
and line breaks.
One question that springs to mind: If the first line is on the same
line as the {% blocktrans %}tag itself (i.e. it has no indentation),
should we strip the subsequent lines based on the indentation of the
second line, or assume that the user wants to keep the text as is?
:)
Please advise.
On Oct 27, 12:41 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Fri, 2007-10-26 at 15:04 +0000, Dmitri Fedortchenko wrote:
> > I've started using blocktrans in my templates and noticed that when
> > using make_messages it includes all the tabs and linebreaks around the
> > text that is surrounded by blocktrans tags.
>
> > For example:
> > {% blocktrans %}
> > Translate this string
> > {% plural %}
> > And this plural string
> > {% endblocktrans %}
>
> > Will turn into:
> > "\t\t\t\tTranslate this string"
> > "\t\t"
> > Plural:
> > "\t\t"
> > "\t\t\t\tAnd this plural string"
>
> > in the .po file... (it affects both normal blocktrans and plural
> > blocktrans)
>
> > This is rather ugly i think. Also in HTML, indentation and linebreaks
> > are generally ignored, so in that sense django does not behave
> > correctly. If you have a string of some length you might not want to
> > place it all on the same line, for the beauty of the syntax...
>
> > So I put in some preliminary work for stripping the translation
> > string.
> > I just realised that my patch only strips the ends of the string which
> > still leaves the middle full of ugliness if you have a multiline
> > msgid.
>
> > Has this ever been discussed?
> > To what extent would the stripping be appropriate? Or perhaps there is
> > a simpler solution that I am missing?
>
> There are really two things at work here: one not so good and one that I
> don't want to change.
>
> The first issue (which is worth fixing) is the leading whitespace and
> particularly the bonus blank lines that appear to be introduced. They
> are worth stripping.
>
> The second issue is what to when we fix blocktrans so that it can
> correctly handle *blocks* of text (things with newlines). In that case,
> I wouldn't want to strip anything beyond a common amount of leading
> whitespace because the source layout can be indicative of meaning
> sometimes (or at least, useful). PO files don't need to preserve
> linebreaks, so the translator can do whatever they want there, but
> arbitrarily stripping and merging feels slightly wrong to me.
>
> Whitespace may well be ignore by HTML processors(not entirely true in
> all cases, but a reasonable generalisation), but it's not ignored by
> humans reading the text. Strip out all whitespace between tags in an
> HTML page and notice how completely unreadable it becomes.
>
> So I'd be happy to include something that stripped the same amount of
> whitespace from the front of every line inside a blocktrans block but
> kept other linebreaks and extra leading whitespace intact. That would
> make the PO file more readable. Anything more compressing than that is
> going to require stronger arguments.
>
> Regards,
> Malcolm
>
> --
> Monday is an awful way to spend 1/7th of your
> life.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
-~--~~~~--~~--~--~---
Stripping spaces and linebreaks from blocktrans?
I've started using blocktrans in my templates and noticed that when
using make_messages it includes all the tabs and linebreaks around the
text that is surrounded by blocktrans tags.
For example:
{% blocktrans %}
Translate this string
{% plural %}
And this plural string
{% endblocktrans %}
Will turn into:
"\t\t\t\tTranslate this string"
"\t\t"
Plural:
"\t\t"
"\t\t\t\tAnd this plural string"
in the .po file... (it affects both normal blocktrans and plural
blocktrans)
This is rather ugly i think. Also in HTML, indentation and linebreaks
are generally ignored, so in that sense django does not behave
correctly. If you have a string of some length you might not want to
place it all on the same line, for the beauty of the syntax...
So I put in some preliminary work for stripping the translation
string.
I just realised that my patch only strips the ends of the string which
still leaves the middle full of ugliness if you have a multiline
msgid.
Has this ever been discussed?
To what extent would the stripping be appropriate? Or perhaps there is
a simpler solution that I am missing?
Index: django/templatetags/i18n.py
===
--- django/templatetags/i18n.py (revision 6603)
+++ django/templatetags/i18n.py (working copy)
@@ -66,10 +66,12 @@
for var,val in self.extra_context.items():
context[var] = val.resolve(context)
singular = self.render_token_list(self.singular)
+singular = singular.strip()
if self.plural and self.countervar and self.counter:
count = self.counter.resolve(context)
context[self.countervar] = count
plural = self.render_token_list(self.plural)
+plural = plural.strip()
result = translation.ungettext(singular, plural, count)
else:
result = translation.ugettext(singular)
Index: django/utils/translation/trans_real.py
===
--- django/utils/translation/trans_real.py (revision 6603)
+++ django/utils/translation/trans_real.py (working copy)
@@ -442,13 +442,13 @@
pluralmatch = plural_re.match(t.contents)
if endbmatch:
if inplural:
-out.write(' ngettext(%r,%r,count) ' %
(''.join(singular), ''.join(plural)))
+out.write(' ngettext(%r,%r,count) ' %
(''.join(singular).strip(), ''.join(plural).strip()))
for part in singular:
out.write(blankout(part, 'S'))
for part in plural:
out.write(blankout(part, 'P'))
else:
-out.write(' gettext(%r) ' %
''.join(singular))
+out.write(' gettext(%r) ' %
''.join(singular).strip())
for part in singular:
out.write(blankout(part, 'S'))
intrans = False
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
