an 'empty' block tag
Hi,
I have a suggestion (with a patch) to save a few key clicks :-)
Do you ever write a template with {% block ... %}{% endblock %} tags
solely as placeholders to be overridden by other templates? I find I am
doing this a lot... and I am too lazy to type the {% endblock %} each
time :-) so I added the {% eblock ... %} tag that does not require an
end tag.
And here is the patch. I am posting it here to see if people think this
is a good idea... if it is, I will create a ticket.
--
Thanks a lot,
Medhat
Index: loader_tags.py
===
--- loader_tags.py (revision 3611)
+++ loader_tags.py (working copy)
@@ -1,5 +1,5 @@
from django.template import TemplateSyntaxError, TemplateDoesNotExist,
resolve_variable
-from django.template import Library, Node
+from django.template import Library, Node, NodeList
from django.template.loader import get_template,
get_template_from_string, find_template_source
from django.conf import settings
@@ -112,27 +112,32 @@
return ''
except:
return '' # Fail silently for invalid included templates.
-
-def do_block(parser, token):
-"""
-Define a block that can be overridden by child templates.
-"""
-bits = token.contents.split()
-if len(bits) != 2:
-raise TemplateSyntaxError, "'%s' tag takes only one argument"
% bits[0]
-block_name = bits[1]
-# Keep track of the names of BlockNodes found in this template, so
we can
-# check for duplication.
-try:
-if block_name in parser.__loaded_blocks:
-raise TemplateSyntaxError, "'%s' tag with name '%s'
appears more than once" % (bits[0], block_name)
-parser.__loaded_blocks.append(block_name)
-except AttributeError: # parser.__loaded_blocks isn't a list yet
-parser.__loaded_blocks = [block_name]
-nodelist = parser.parse(('endblock',))
-parser.delete_first_token()
-return BlockNode(block_name, nodelist)
-
+
+def do_block_func(empty=False):
+def do_block(parser,token):
+"""
+Define a block that can be overridden by child templates.
+"""
+bits = token.contents.split()
+if len(bits) != 2:
+raise TemplateSyntaxError, "'%s' tag takes only one
argument" % bits[0]
+block_name = bits[1]
+# Keep track of the names of BlockNodes found in this
template, so we can
+# check for duplication.
+try:
+if block_name in parser.__loaded_blocks:
+raise TemplateSyntaxError, "'%s' tag with name '%s'
appears more than once" % (bits[0], block_name)
+parser.__loaded_blocks.append(block_name)
+except AttributeError: # parser.__loaded_blocks isn't a list
yet
+parser.__loaded_blocks = [block_name]
+if empty:
+nodelist = NodeList()
+else:
+nodelist = parser.parse(('endblock',))
+parser.delete_first_token()
+return BlockNode(block_name, nodelist)
+return do_block
+
def do_extends(parser, token):
"""
Signal that this template extends a parent template.
@@ -172,6 +177,7 @@
return ConstantIncludeNode(path[1:-1])
return IncludeNode(bits[1])
-register.tag('block', do_block)
+register.tag('block', do_block_func())
+register.tag('eblock', do_block_func(True))
register.tag('extends', do_extends)
register.tag('include', do_include)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Should we have another 'post_save' signal?
Hi, I was trying to create a thumbnail from an ImageField when the object is saved. I tried different things but none of them worked the way I wanted. Then I thought of using the post_save signal to do it only to discover that this signal is sent after the object itself is saved but before all the uploaded files in FileField-derived fields are saved. Should the post_save signal be moved to after the files are saved, or can we have another signal that is fired then? -- Thanks, Medhat --~--~-~--~~~---~--~~ 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: Enhancement:Open tag cannot support multiline
I don't really feel strongly either way about these tags since I can
see the argument that if the tag is too long maybe that means that the
template is doing more than it should. But I am responding mainly to
say that it seems that comments {# #} have the same issue; so something
like:
{#
{% if x %}
blah blah blah
{% endif %}
#}
will not be commented out. And I think this is a far more common
scenario.
--
Medhat
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Is this a bug in get_list_or_404?!
Hi,
This is the current implementation of get_list_or_404 in
django.shortcuts
---
def get_list_or_404(klass, *args, **kwargs):
obj_list = list(klass._default_manager.filter(*args, **kwargs))
if not obj_list:
raise Http404
return obj_list
---
The problem is that this will return a list, not a query set. So, you
cannot do something like:
objects = get_list_or_404(Item,name=x).order('-age')
notice that I applied .order() to the result of get_list_or_404
wouldn't it be better to change the implementation to:
---
def get_list_or_404(klass, *args, **kwargs):
obj_list = klass._default_manager.filter(*args, **kwargs)
if obj_list.count() == 0:
raise Http404
return obj_list
---
--
Thanks,
Medhat
--~--~-~--~~~---~--~~
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: #2333 Pt 3 - Test system fixture data
Is there any update on including this into trunk?! I have been checking the ticket daily :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
custom settings for tests
Ok, Here is something I was thinking about and I would like to see if anybody else had a similar need, or if I am just missing something. When writing unit tests, in a similar way to having fixtures as proposed in http://code.djangoproject.com/ticket/2333 I would like to have custom settings data for each test. I want this mainly to control which apps are installed for some of the tests. Since in my code, in some manager functions I get all models that have a foreign key relation to that manager's model, and I don't want to keep updating my test everytime I add a new model with a foreign key. I can see this also to be useful with middleware, if you want to test a specific middleware with other ones present or absent. Does that make sense, or am I missing something?! -- Thanks, Medhat --~--~-~--~~~---~--~~ 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: New Django ticket system workflow ideas
I think this should be really high on the priority list of the core django team because, as many have said, everybody here is a volunteer, and personally many times I would be thinking of investing some time to implement a feature in django thinking that it might be useful for other people (instead of just implementing a workaround that will only work for me) but then I get discouraged because I know that if I create a ticket with a patch, most probably my work will get lost among all the other tickets, and then I spend my time on something else that I would consider worthwhile. If I feel that the time I will spend doing something will not be in vain, I think I will be willing to spend more time on sharing ideas and creating patches. I am not trying to accuse anybody of any wrongdoing, I am just stating a fact about how I decide how to spend my spare time (and probably others do the same thing) On a more positive note: Are you guys aware of this: http://trac.edgewall.org/wiki/TracTicketsCustomFields this might help in classifying tickets without overloading the title or keyword fields (abd having some checkboxes will make it easier for people to know all the options instead of just *knowing* that I need to add [patch] or any other magic string to the title or keyword fields) Also, I haven't looked at this, but if trac would allow some fields to only be edited by core developers, I would think that at least one of priority and severity could help in planning and directing people for where they should spend their time. Just my 2 cents :-) -- Thanks, Medhat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Is this group moderated, or is it a bug with google groups?
So many times I send messages to the group, but my message does not appear at all, or it might appear a day or two after I actually send it, which of course makes it appear down on the list, and nobody really sees it. -- Thanks, Medhat --~--~-~--~~~---~--~~ 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 idea for urls.py and maybe reverse url resolving
Resending another time... -- Ok, I have been thinking about this for about an hour now... and I would like to get some feedback from you. First, the problem that I was initially trying to solve: I have multiple models, all of which can be tagged. I also have a Tag model with a custom manager that can return tags for an item, a list of items, or for a model type; or inversly you can give it some tags, and it will give you back the items that are tagged with that tag (optionally you can restrict the returned items to a type) And I have the following urls: /tags/x/ in the root urls.py (will return all items that have tag x irrespective of their type) /photos/tags/x/ in the photos application's urls.py (will return all photos that have tag x) both of these urls call the same view, but the second one will pass the type in the extra options where in the first one it will default to None (from the default valie in the view) In the final html will have a list of other tags that you can click. For example, first I will get all the photos that have tag x, then get all the tags of these photos, and have a link for each one of these tags on the final page. My problem is that the link for tag y in the second case should be /photos/tags/y and in the first case should be /tags/y At first this seemed like a good candidate for some Reverse URL hackery... but then I thought, when the url matching is done, when does django get rid of what was matched when it finds an include?! Imagine if the view is defined as: def view_function(context,stem, ) where stem is the part of the url that was matched before jumping into the urls.py that has the called view that would solve my problem (and probably a lot of the problems that led to the creation of urlresolver.reverse. I am willing to work on a patch that will implement this. But I also understand that this will be a huge backwards incompatible change (since "stem" will need to be added to each view function) So, I am expecting that people will not be so warm to the idea. Another alternative, which I don't like as much, but will be backwards compatible is to add "stem" to the request object (even though I understand this is not really a request property) So, I would like to hear what you guys think. -- Thanks! Medhat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
A question related to URLConf, Reverse URL, etc...
Ok, I have been thinking about this for about an hour now... and I would like to get some feedback from you. First, the problem that I was initially trying to solve: I have multiple models, all of which can be tagged. I also have a Tag model with a custom manager that can return tags for an item, a list of items, or for a model type; or inversly you can give it some tags, and it will give you back the items that are tagged with that tag (optionally you can restrict the returned items to a type) And I have the following urls: /tags/x/ in the root urls.py (will return all items that have tag x irrespective of their type) /photos/tags/x/ in the photos application's urls.py (will return all photos that have tag x) both of these urls call the same view, but the second one will pass the type in the extra options where in the first one it will default to None (from the default valie in the view) In the final html will have a list of other tags that you can click. For example, first I will get all the photos that have tag x, then get all the tags of these photos, and have a link for each one of these tags on the final page. My problem is that the link for tag y in the second case should be /photos/tags/y and in the first case should be /tags/y At first this seemed like a good candidate for some Reverse URL hackery... but then I thought, when the url matching is done, when does django get rid of what was matched when it finds an include?! Imagine if the view is defined as: def view_function(context,stem, ) where stem is the part of the url that was matched before jumping into the urls.py that has the called view that would solve my problem (and probably a lot of the problems that led to the creation of urlresolver.reverse. I am willing to work on a patch that will implement this. But I also understand that this will be a huge backwards incompatible change (since "stem" will need to be added to each view function) So, I am expecting that people will not be so warm to the idea. Another alternative, which I don't like as much, but will be backwards compatible is to add "stem" to the request object (even though I understand this is not really a request property) So, I would like to hear what you guys think. -- Thanks! Medhat --~--~-~--~~~---~--~~ 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: A question related to URLConf, Reverse URL, etc...
Here is even a better idea...
in your urls.py when you "from django.conf.urls.defaults import *" this
will import 'stem' in addition to the usual things. In any url pattern,
if you add {'param_name':stem} to the extra options, your view will get
a keyword argumant called 'param_name' and will have the value of the
part of the url that matched *before* going into that urls.py file.
example:
--- urls.py ---
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^categories/', include('apps.tags.urls')),
)
--- apps/tags/urls.py ---
from django.conf.urls.defaults import *
urlpatterns = patterns('apps.tags.views',
(r'^(?P[^/]*)/$','tag_list',{'stem':stem}),
)
---
In that case the url http://www.example.com/tags/x/ will call
apps.tags.views.tag_list and pass it the request object and two keyword
parameters: tag = 'x' and stem = /categories/
I already have a patch that does this. I don't have unit tests or
documentation yet. But if this looks like a patch that would be
accepted, I can definitely work on the tests and documentation.
--
Thanks,
Medhat
--~--~-~--~~~---~--~~
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: A question related to URLConf, Reverse URL, etc...
the url should be http://www.example.com/categories/x/
--
Medhat
On Jan 26, 12:12 pm, "medhat" <[EMAIL PROTECTED]> wrote:
> Here is even a better idea...
>
> in your urls.py when you "from django.conf.urls.defaults import *" this
> will import 'stem' in addition to the usual things. In any url pattern,
> if you add {'param_name':stem} to the extra options, your view will get
> a keyword argumant called 'param_name' and will have the value of the
> part of the url that matched *before* going into that urls.py file.
>
> example:
>
> --- urls.py ---
>
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('',
> (r'^categories/', include('apps.tags.urls')),
> )
>
> --- apps/tags/urls.py ---
>
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('apps.tags.views',
> (r'^(?P[^/]*)/$','tag_list',{'stem':stem}),
> )
>
> ---
>
> In that case the urlhttp://www.example.com/tags/x/will call
> apps.tags.views.tag_list and pass it the request object and two keyword
> parameters: tag = 'x' and stem = /categories/
>
> I already have a patch that does this. I don't have unit tests or
> documentation yet. But if this looks like a patch that would be
> accepted, I can definitely work on the tests and documentation.
>
> --
> Thanks,
> Medhat
--~--~-~--~~~---~--~~
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: A question related to URLConf, Reverse URL, etc...
In the case of the parent->child->grandchild, the grandchild view will
get the stem for everything before the grandchild urls.py (In my case,
I really did not care how many urls.py it went through, my main problem
is that the same view can be called by multiple urls, and I wanted in
each case to have the stem available to the template)
As for doing it as a middleware, it is probably doable, but it does not
seem right to me... in the case of the user middleware, the user is an
actual property of the request, but the stem does not feel like it
belongs to the request (I know I am being a purist here :-)) the stem
is more an internal thing that depends on how the project is organized
and how urls.py files are including each other.
On Jan 26, 2:04 pm, "SmileyChris" <[EMAIL PROTECTED]> wrote:
> I'd suggest doing it as middleware which appends to the request (sorta
> like the user middleware). This way it's available in the view as well
> as the template context (if you pass it explicitly or use the request
> context processor).
>
> Also, what about urls.py deeper than just parent->child? Maybe stem
> should be a list of matches, one for each URLResolver?
>
> On Jan 27, 7:12 am, "medhat" <[EMAIL PROTECTED]> wrote:
>
> > Here is even a better idea...
>
> > in your urls.py when you "from django.conf.urls.defaults import *" this
> > will import 'stem' in addition to the usual things. In any url pattern,
> > if you add {'param_name':stem} to the extra options, your view will get
> > a keyword argumant called 'param_name' and will have the value of the
> > part of the url that matched *before* going into that urls.py file.
>
> > example:
>
> > --- urls.py ---
>
> > from django.conf.urls.defaults import *
>
> > urlpatterns = patterns('',
> > (r'^categories/', include('apps.tags.urls')),
> > )
>
> > --- apps/tags/urls.py ---
>
> > from django.conf.urls.defaults import *
>
> > urlpatterns = patterns('apps.tags.views',
> > (r'^(?P[^/]*)/$','tag_list',{'stem':stem}),
> > )
>
> > ---
>
> > In that case the urlhttp://www.example.com/tags/x/willcall
> > apps.tags.views.tag_list and pass it the request object and two keyword
> > parameters: tag = 'x' and stem = /categories/
>
> > I already have a patch that does this. I don't have unit tests or
> > documentation yet. But if this looks like a patch that would be
> > accepted, I can definitely work on the tests and documentation.
>
> > --
> > Thanks,
> > Medhat
--~--~-~--~~~---~--~~
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: A question related to URLConf, Reverse URL, etc...
Well, I went ahead and created a patch for this. It is in ticket 3402
(http://code.djangoproject.com/ticket/3402)
--
Thanks,
Medhat
On Jan 26, 12:18 pm, "medhat" <[EMAIL PROTECTED]> wrote:
> the url should behttp://www.example.com/categories/x/
>
> --
> Medhat
>
> On Jan 26, 12:12 pm, "medhat" <[EMAIL PROTECTED]> wrote:
>
> > Here is even a better idea...
>
> > in your urls.py when you "from django.conf.urls.defaults import *" this
> > will import 'stem' in addition to the usual things. In any url pattern,
> > if you add {'param_name':stem} to the extra options, your view will get
> > a keyword argumant called 'param_name' and will have the value of the
> > part of the url that matched *before* going into that urls.py file.
>
> > example:
>
> > --- urls.py ---
>
> > from django.conf.urls.defaults import *
>
> > urlpatterns = patterns('',
> > (r'^categories/', include('apps.tags.urls')),
> > )
>
> > --- apps/tags/urls.py ---
>
> > from django.conf.urls.defaults import *
>
> > urlpatterns = patterns('apps.tags.views',
> > (r'^(?P[^/]*)/$','tag_list',{'stem':stem}),
> > )
>
> > ---
>
> > In that case the urlhttp://www.example.com/tags/x/willcall
> > apps.tags.views.tag_list and pass it the request object and two keyword
> > parameters: tag = 'x' and stem = /categories/
>
> > I already have a patch that does this. I don't have unit tests or
> > documentation yet. But if this looks like a patch that would be
> > accepted, I can definitely work on the tests and documentation.
>
> > --
> > Thanks,
> > Medhat
--~--~-~--~~~---~--~~
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: A question related to URLConf, Reverse URL, etc...
Well, Matt and Adrian closed the ticket with some similar argument.
But I respectfuly disagree :-)
In muramas example above, (r'^news/', 'myproject.apps.news.urls',
{'stem':'news'}) this does not solve my problem, because in my case
(assuming that this pattern is in an included urls.py) the stem is not
'news' it is whatever was matched in the urls.py that included this
current one.
In the ticket the argument was that in the including urls.py you can
have something like:
(r'^(?Pnews)/', include('myproject.apps.news.urls')),
and then use section as a kwarg. I see some problems with this:
1. This will only work for one level of includes (granted I only have
one urls.py that is a second level, and probably no one will ever need
more than two levels) Of course you can do something similar for more
levels but it will be very messy.
2. The more you add parameters to the pattern, the more it becomes
complex and harder to read.
3. Doing it this way (?Pnews) will force me to have a
'section' kwarg for every view in the included urls.py while I only
need it for only one view.
4. In the django documentation, it says the following on the URL
Dispatcher page "Whenever Django encounters include(), it chops off
whatever part of the URL matched up to that point and sends the
remaining string to the included URLconf for further processing." And
that's what sounded weird to me... "it chops off..." why chop off
something that seems to be useful to pass to the view?
In my case, as I mentioned before, adding /tags at the end of almost
any url will display a page with the tags of the item that was viewed.
And on that page when constructing the links for the tags I want it to
include the stem. So for example /galleries/tags will show only the
tags in galleries (and all these tags will be links that will show
gallery items with that tag) and /galleries/2004/tags will do the same
thing but only for galleries of pictures that were taken in 2004. Same
thing can be done for /blog/tags etc...
My solution (the one in the patch in ticket 3402 is fully backward
compatible, will only affect the views that *need* the stem, and is
not affected by how many levels of includes there are. And imho I
think it solves the problem in a simple non-obtrusive way.
So, I would like you guys to reconsider the patch in light of this
more in-depth explanation :-)
--
Thanks,
Medhat
On Jan 31, 8:02 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I actually wrote a patch yesterday to solve the same problem, but for
> different reasons (and using a different method). From my
> perspective, the larger problem that access to the URL 'stem' can
> solve is to decouple apps from projects, making it much easier to
> write relocatable, "drop-in" applications.
>
> Currently, if an application wants to construct absolute URL's for
> anything, one needs to either hardcode the 'stem' into the
> application, and into the project's URLconf. (For most things, of
> course, it is at least possible to use relative URLs, but it can
> certainly be less convenient sometimes..) With the solution described
> above (and in medhat's patch) you still need to know what the
> particular application wants the stem to be passed as, so in a lot of
> cases, it seems you might be just as well doing this:
>(r'^news/', 'myproject.apps.news.urls', {'stem':'news'})
> instead of:
>(r'^news/', 'myproject.apps.news.urls', {'stem':stem})
>
> The solution I went with was to add the stem transparently to the
> request variable as the URLs are resolved. (I agree it's not exactly
> a property of the request itself, so this might be suboptimal; it is
> at least backwards compatible, though..) This would allow application
> authors an easy way to refer to themselves absolutely, and let folks
> installing those applications do so at any URL prefix with only a
> simple include, and without having to figure out what stem variable
> the app wants to be passed.
--~--~-~--~~~---~--~~
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: OneToOneField behavior doesn't match docs
[EMAIL PROTECTED] wrote: > Joseph Kocherhans wrote: > > The current trunk and magic-removal docs say this about OneToOneField: > > [snip] > > No feedback, so I've commited a patch. OneToOneField now behaves like > ForeignKey for adding objects in the admin system, and is displayed as > a read only field for the change form. Here's the ticket again. > > http://code.djangoproject.com/ticket/1681 > > Joseph Wouldn't moving this to the base class also affect ManyToManyField? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Reverse URL lookup implementation
Adrian Holovaty wrote: > On the plane from London to Chicago yesterday, I implemented something > that's been discussed on this list lately -- "reverse" URL creation. > > I've attached a new urlresolvers.py to this e-mail. It's intended to > replace the one in django/core, and it works with magic-removal only. > (To use it with trunk, just replace the import line at the top to > import Http404 from django.core.exceptions instead of django.http.) > I've also attached unit tests. > > [...] > > Thoughts? > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > Hi, Is there any reason this is not added to the repository? -- Thanks! Medhat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
A bug in reverse url lookup? (and a possible patch)
Hi
Reverse URL lookup
(http://groups.google.com/group/django-developers/browse_thread/thread/a5d12bc4fb073f24/83d7e4cb5f35ed08)
is one of the things that I am interested in in django.
The way I see myself using this will be roughly as follows: each
application will have a 'root' view. Using reverse URL lookup, it will
get its 'root' URL, and then the application will construct its
internal URLs using this root URL as a prefix. (of course this can
still be used for multiple 'root' URLs, the application will still know
its root views)
I was trying RegexURLResolver.reverse to accomplish that but it seemed
that (1) it did not go into included urls.py, and (2) even if it did it
will not add the prefix url from the including urls.py. I have a patch
to fix both of these problems.
I know that probably a ticket would be the best place to submit the
patch, I just wanted more people to look at it first, since I still
consider myself new with django, and I wanted to make sure that I did
not miss something, or if people will planning on using this
differently.
--
Thanks!
Medhat
Index: urlresolvers.py
===
--- urlresolvers.py (revision 2996)
+++ urlresolvers.py (working copy)
@@ -23,6 +23,25 @@
dot = callback.rindex('.')
return callback[:dot], callback[dot+1:]
+def reverse_helper(regex, *args, **kwargs):
+"""
+Does a "reverse" lookup -- returns the URL for the given
args/kwargs.
+The args/kwargs are applied to the regular expression in this
+RegexURLPattern. For example:
+
+>>> RegexURLPattern('^places/(\d+)/$').reverse_helper(3)
+'places/3/'
+>>>
RegexURLPattern('^places/(?P\d+)/$').reverse_helper(id=3)
+'places/3/'
+>>>
RegexURLPattern('^people/(?P\w\w)/(\w+)/$').reverse_helper('adrian',
state='il')
+'people/il/adrian/'
+
+Raises NoReverseMatch if the args/kwargs aren't valid for the
RegexURLPattern.
+"""
+# TODO: Handle nested parenthesis in the following regex.
+result = re.sub(r'\(([^)]+)\)', MatchChecker(args, kwargs),
regex.pattern)
+return result.replace('^', '').replace('$', '')
+
class MatchChecker(object):
"Class used in reverse RegexURLPattern lookup."
def __init__(self, args, kwargs):
@@ -108,24 +127,8 @@
return self.reverse_helper(*args, **kwargs)
def reverse_helper(self, *args, **kwargs):
-"""
-Does a "reverse" lookup -- returns the URL for the given
args/kwargs.
-The args/kwargs are applied to the regular expression in this
-RegexURLPattern. For example:
+return reverse_helper(self.regex, *args, **kwargs)
->>> RegexURLPattern('^places/(\d+)/$').reverse_helper(3)
-'places/3/'
->>>
RegexURLPattern('^places/(?P\d+)/$').reverse_helper(id=3)
-'places/3/'
->>>
RegexURLPattern('^people/(?P\w\w)/(\w+)/$').reverse_helper('adrian',
state='il')
-'people/il/adrian/'
-
-Raises NoReverseMatch if the args/kwargs aren't valid for the
RegexURLPattern.
-"""
-# TODO: Handle nested parenthesis in the following regex.
-result = re.sub(r'\(([^)]+)\)', MatchChecker(args, kwargs),
self.regex.pattern)
-return result.replace('^', '').replace('$', '')
-
class RegexURLResolver(object):
def __init__(self, regex, urlconf_name):
# regex is a string representing a regular expression.
@@ -180,10 +183,23 @@
def resolve500(self):
return self._resolve_special('500')
+def reverse_helper(self, viewname, *args, **kwargs):
+try:
+sub_match = self.reverse(viewname, *args, **kwargs)
+result = reverse_helper(self.regex, *args, **kwargs)
+return result + sub_match
+except NoReverseMatch:
+raise NoReverseMatch
+
def reverse(self, viewname, *args, **kwargs):
for pattern in self.urlconf_module.urlpatterns:
-if pattern.callback == viewname:
+if isinstance(pattern, RegexURLResolver):
try:
+return pattern.reverse_helper(viewname, *args,
**kwargs)
+except NoReverseMatch:
+continue
+elif pattern.callback == viewname:
+try:
return pattern.reverse_helper(*args, **kwargs)
except NoReverseMatch:
continue
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
