Admin "View on site" link broken
Hi,
I'm having a problem with the Admin "View on site" button. According
to http://www.djangoproject.com/documentation/model_api/#get-absolute-url
all I need to do is add a get_absolute_url() method to my model
objects and the admin interface will gain a "View on site" button that
links to my application's view of the object.
My model objects have a get_absolute_url() method, and the View on
site button appears as expected, however, the "View on site" button
links to strange relative urls like "../../../r/10003".
I dug around a little. The change_form.html template contains this code:
{% if has_absolute_url %}{% trans "View on site"
%}{% endif%}
This looks like a bug with some history. What is going on here?
Alan.
--
Alan Green
[EMAIL PROTECTED] - http://bright-green.com
--~--~-~--~~~---~--~~
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: Admin "View on site" link broken
Hi Alan, On 8/27/06, Alan Green <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm having a problem with the Admin "View on site" button. According [snip] > My model objects have a get_absolute_url() method, and the View on > site button appears as expected, however, the "View on site" button > links to strange relative urls like "../../../r/10003". [snip] While not a bug, this could certainly be documented better. Just add the following to your root urlconf and things will work as expected: ( r'^r/', include( 'django.conf.urls.shortcut' ) ), Hope that helps, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django Test framework commits (r3658-r3661)
Hi all,Revisions 3658-3661 are the commits of the first two phases of the Django Testing Framework. These changes should have no impact on any existing project. However, should you wish to unit test your Django application, there is now a framework (controlled by ./manage.py test) that will allow you to do so. In order to eat our own dogfood, the Django internal tests have been migrated to use the new framework. This is changeset 3661. Although this changeset looks large, it isn't actually that complex - it's mostly minor format changes, plus the migration of all the 'othertests' into the 'regressiontests' package.I am still working on some documentation for these new features. The documentation should be ready some time in the next week. In the meantime, the commentary on ticket #2333, the various django-dev discussions, and the Django internal tests should give you an indication of what is possible, and a vague idea of how to do it. As I commit, all the unit tests are passing for me; If I've borken anything in the migration, or I've forgotten to 'svn add' a file somewhere, let me know. This is not the end of the road - there is still more work to be done on the testing framework. The next feature on my list is the implementation of test fixtures. As always, comments/suggestions are welcomeYours,Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[patch] URLField says all links to Wikipedia are invalid
Akismet thinks this bug is spam, so I cannot submit it to Trac.
A URLField will report that all links to en.wikipedia.org are invalid,
because urllib2, along with wget and libwww-perl, are blocked by
default.
http://mail.wikipedia.org/pipermail/wikitech-l/2003-December/019849.html
This is due to people writing poorly-designed bots, not due to it being
a violation of Wikipedia policy to access the site automatically, so
a good fix is to set the User-Agent header to indicate that Django is
making the request. A patch is attached; it's against 0.95 but this
also affects the trunk.
It would be nice if the Django version could be included in the
User-Agent, but I didn't see where it was accessible from the code.
--
Shields.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
--- django/core/validators.py.orig 2006-08-21 06:13:11.0 +
+++ django/core/validators.py 2006-08-27 00:43:37.0 +
@@ -203,8 +203,10 @@
def isExistingURL(field_data, all_data):
import urllib2
+req = urllib2.Request(url=field_data)
+req.add_header('User-Agent', 'Django/0.0')
try:
-u = urllib2.urlopen(field_data)
+u = urllib2.urlopen(req)
except ValueError:
raise ValidationError, gettext("Invalid URL: %s") % field_data
except urllib2.HTTPError, e:
RowLevelPermission branch Automatic creation of object rlp doesn't work in the admin for inline edited foreign key fields
In the following model construction using current svn RowLevelPermission branch: class Object: name=CharField(...) class Meta: row_level_permissions=True class Admin: grant_change_row_level_perm=True grant_delete_row_level_perm=True class ObjectProperty: object=ForeignKey(Object, edit_inline=models.TABULAR) some_property=CharField(...) class Meta: row_level_permissions=True class Admin: grant_change_row_level_perm=True grant_delete_row_level_perm=True ObjectProperty objects can be created and edited nicely within the Object admin form but respective ObjectProperty row level permissions are not being set automatically for ObjectProperty objects when new ObjectProperty objects are being created. I tried to post this as ticket to django trac but askimet rejected my ticket as spam. Regards, volker --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Row level permission problem in admin for inline edited objects
While toying around with the new rlp-branch i ran into the following observations: Row level permissions work great and as described in the documentation wiki when objects are being accessed through their admin forms via the admin index page. If i try to edit related objects inline (as in the example) there are two cases that do not work as i would have expected: class Object: name=CharField(...) class Meta: row_level_permissions=True class Admin: grant_change_row_level_perm=True grant_delete_row_level_perm=True show_all_rows = False class ObjectProperty: object=ForeignKey(Object, edit_inline=models.TABULAR) some_property=CharField(...,core=True) class Meta: row_level_permissions=True class Admin: grant_change_row_level_perm=True grant_delete_row_level_perm=True show_all_rows = False 1.) 'ObjectProperty' objects can be created and edited nicely within the 'Object' admin form but respective 'ObjectProperty' row level permissions are not being set automatically. 2.) When editing 'ObjectProperty' in the admin the ForeignKey box displays all possible 'Object' choices without regard to the logged in user's row level permissions. I tried to file this as ticket in the trac but askimet spam protection would not let me. Hope this is right here. Best regards, littleswo --~--~-~--~~~---~--~~ 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: [patch] URLField says all links to Wikipedia are invalid
I would be +1 on this if it included the site domain in the user-agent.
having it this way will just cause wikipedia to block it when a
single badly behaving django-bot uses it.
--I
On 27/08/2006, at 12:43 PM, [EMAIL PROTECTED] wrote:
> Akismet thinks this bug is spam, so I cannot submit it to Trac.
>
>
> A URLField will report that all links to en.wikipedia.org are invalid,
> because urllib2, along with wget and libwww-perl, are blocked by
> default.
>
> http://mail.wikipedia.org/pipermail/wikitech-l/2003-December/
> 019849.html
>
> This is due to people writing poorly-designed bots, not due to it
> being
> a violation of Wikipedia policy to access the site automatically, so
> a good fix is to set the User-Agent header to indicate that Django is
> making the request. A patch is attached; it's against 0.95 but this
> also affects the trunk.
>
> It would be nice if the Django version could be included in the
> User-Agent, but I didn't see where it was accessible from the code.
> --
> Shields.
>
>
> > --- django/core/validators.py.orig 2006-08-21 06:13:11.0 +
> +++ django/core/validators.py 2006-08-27 00:43:37.0 +
> @@ -203,8 +203,10 @@
>
> def isExistingURL(field_data, all_data):
> import urllib2
> +req = urllib2.Request(url=field_data)
> +req.add_header('User-Agent', 'Django/0.0')
> try:
> -u = urllib2.urlopen(field_data)
> +u = urllib2.urlopen(req)
> except ValueError:
> raise ValidationError, gettext("Invalid URL: %s") %
> field_data
> except urllib2.HTTPError, e:
--
Ian Holsman
[EMAIL PROTECTED]
join http://gypsyjobs.com the marketplace for django developers
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Rails has a Naked Objects tool (aka automagic gui)
I hadn't seen this mentioned on the lists. http://streamlined.relevancellc.com/articles/2006/08/02/screencast-available --~--~-~--~~~---~--~~ 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: Rails has a Naked Objects tool (aka automagic gui)
On 8/27/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > I hadn't seen this mentioned on the lists. There are a couple of Rails admin systems floating around; one even (literally) copies the Django admin look and feel. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Rails has a Naked Objects tool (aka automagic gui)
I like the idea. but the implementation.. ugh.. I don't think it would be useable on a large scale system. all of these types of things should get as much info as possible out of the database/models that exist having to retype the relationships sounds yuko to me. but hey... I'm not a ruby guy.. maybe they like doing these kind of things. On 28/08/2006, at 12:08 PM, James Bennett wrote: > > On 8/27/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: >> I hadn't seen this mentioned on the lists. > > There are a couple of Rails admin systems floating around; one even > (literally) copies the Django admin look and feel. > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin > -- Ian Holsman [EMAIL PROTECTED] http://peopleintopoker.com/ -- where the poker people go --~--~-~--~~~---~--~~ 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: Re: Rails has a Naked Objects tool (aka automagic gui)
On 8/27/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > all of these types of things should get as much info as possible out > of the database/models that exist > having to retype the relationships sounds yuko to me. DHH has a thing about that; he doesn't think information about admin representations belongs in models. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Django Test framework commits (r3658-r3661)
Hi again, Following some concerns from Adrian, part of the testing patches have been rolled back (as of r3666). The testing framework itself will continue to work; however, the 'pseudo client' will be unable to inspect template specific details. Apologies for any inconvenience. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: Re: Validation Aware Models and django.forms on steroids
Personally, I like the form exception thing, but if enough people think it's un-Pythonic or too expensive to use an exception for it, then I can get behind that. I like a lot of the stuff in Joseph's proposal, especially the method of handling read-only fields (that would solve a lot of common problems people run into currently). There are two things that I'd like to see hammered out as we do this, though: 1. When, exactly, the "manipulator" (whatever name we end up choosing; I like Form) fills in default values. 2. A sexier syntax for using manipulators in views. Stripped of the form-as-exception, both these proposals boil down to almost the same basic pattern we see now. There's a lot to be said for not breaking compatibility with existing views, but it's always felt slightly clunky to me; I'd love to see something better. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
