Re: admin-interface: move up/down proposal
Konstantin Khilkevitch wrote: > I believe ticket 13, now in accepted queue, deals with this > functionality: http://code.djangoproject.com/ticket/13 I'm not sure it's exactly the same, as ticket #13 only deals with the ordering of related objects with respect to a particular object. It would be useful to be able to order objects in and of themselves, too. Jason --~--~-~--~~~---~--~~ 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: Handling exceptions raised while processing requests from django.test.client.Client
Also, I forgot to say, a quick grep of the Django code reveals that the db rollback code is currently the only listener for the got_request_exception signal. I've moved the signal dispatch line outside of the if statement in the base handler with the effect that it is now always dispatched as you suggest. The assumption here is that a DB rollback is not a problematic thing to do when in debug mode. As for the resetting of __builtin__._, what is the expected value during the execution of django.contrib.auth.forms? Is it the standard gettext or django.utils.translation.gettext_lazy? --~--~-~--~~~---~--~~ 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: Handling exceptions raised while processing requests from django.test.client.Client
Afternoon: > As for the resetting of __builtin__._, what is the expected value > during the execution of django.contrib.auth.forms? Is it the standard > gettext or django.utils.translation.gettext_lazy? It's django.utils.translation.gettext. Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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: Schema Evolution branch?
On 1/21/07, Victor Ng <[EMAIL PROTECTED]> wrote: > > I ought to be able to start committing code in the next day or two. > argh... i hate hard disks. I kinda like 'em. I remember booting off floppies. Not much fun. :) --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
Howdy Graham, > +1 for anything that makes the dev server multi-threaded. I'm hoping > there might be a way to do this without introducing a dependency on > CherryPy. I believe the wsgiserver.py file from the CherryPy distribution is independent from the rest of the framework. I know, for example, that Chad Whitacre (from the Aspen project: http://www.zetadev.com/software/aspen/) includes it in Aspen without any of the rest of CherryPy. If Django did the same thing then it should work without having to require that users also install CherryPy. --gordon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
translations - cross post. maybe this is a better place to discuss this :)
after searching and reading all the posts related to internalization
and multilanguange, my first question is if there is any active
development to integrate or make easy translations in the django core,
and if not, if there are any people who would be interested in a joint
effort.
in my experience, this is one of the most difficult, but necessary
functionality in every CMS or framework.
first, the complexity of the usage cases, i identify at first hand the
following major differences:
a) a site with one main language that offers translations of all or
some of their content.
these normally have a page like www.example.com/about that offer a link
to change language where you read the about page but in another
language.
b) sites that are multilangual but are not necesarily a translation of
one language to another.
this sites may have different structure and content, mostly offering
the multilanguage capability in the url or domain:
en.example.com / es.example.com or even www.example.com /
www.ejemplo.com :)
or... www.example.com/es/informacion / www.example.com/en/about and so
on...
there are already middlewares out there that pretty much cover case b),
except for model creation etc...
case a) seems to be a little more complicated.
now i am going to describe how it should/could be for a programmer,
independently of how this could be implemented behind the scenes, in a
DRY way:
class Page(models.Model):
titel = models.CharField(maxlength=200)
text = models.TextField()
class Admin:
pass
class Translation:
pass
At this point, the model Page should already have multilanguage
capabilities.
when accessing the Admin interface, and create a new Page, in the Page
Form there could be a dropdown allowing you to choose from the
languages you have defined in settings.py. Next to that dropdown, you
have a link (add translation) that saves the current Page and redirects
to a new page form to add a translation. Next to the
link in Page Form, you have links to all translations that already
exist:
Then we could expand functionality allowing the following example:
class Page(models.Model):
title =
text =
date = models.DateTime...
publish = models.Boolean.. .
class Admin:
pass
class Translation:
self.fields = (title, text)
Some times there are fields that really don't need to be translated (at
the model level), like date or a boolean.
so you can specify what fields should be translated to avoid redundant
database usage.
The examples above allow you to create a root document in any language,
so up till now it is usable for both case a) and b). Lets say you want
to force the users to create a french language always, and then allow
translations of other languages...
.
class Translation:
self.root = ('fr',)
users may only create "original" documents in french, other languages
may not be "parent" Pages
or maybe just a default
class Translation:
self.default = 'en'
or maybe not even allowing a document to be created without creating
the translations...
class Translation:
self.force = ('fr','en')
so now the Page and the translation fields are on the same screen and
must be created at once.
The functionality can go on and on... different options on how the
translation forms in the admin interface can be shown (like field next
to translation field, or first all language elementes in french and
then all the english ones.. etc...)...
What functionality do we need in the views?
when we would use something like:
>>pages = Page.objects.all()
we would use:
>>pages = _lang(Page.objects.all())
(and would filter out all other languages than the current one (from
request or cookie or whatever)
_lang can accept a language to force a specific one...
>> pages = _lang(Page.objects.all(),'en')
(get the english ones)
>>pages = _rootlang(Page.objects.all(),)
get root is similar to _lang, except that it returns the list of the
translations that exist for the root languange.
in the example above, we set root to french. _rootlang will search all
the french pages, get the translations for those documents. if you
want, it can return the original root languange version automatically
when no translation for it exists...
well, this is an original draft idea and needs some refinment, but from
the user perspective, both as an application user or as the programmer
using the framework, it would seem to me that this approach would be
intuitive and adheres to the DRY philosophy.
Now how this is IMPLEMENTED... is another story :D
maybe it would be good to be able to choose between: one table for
"translation relationships" and all languanges of a model is stored in
one table, or one table per translation, i think these are things that
might depend on the application, so maybe it would be nice if we could
choo
using select_related() and selecting DB table fields
Hello.. .. brought this up in the IRC channel yesterday, but didn't come to a final conclusion at the time. My use-case is really simple; I'd like to do something like this from the django DB API: SELECT trackback.title, blog.name, blog.url FROM trackback INNER JOIN blog ON trackback.blog_id = blog.id The only way of getting certain fields from a table (that I have found) is using values() on a QuerySet, but then I have a ValueQuerySet, which wont be populated by select_related(). Now, I understand this would break the model object to table row mapping of the QuerySet (objects woulnd't be complete if some fields were missing), but that kind of query is such a common one that I'm really surprised that I now seem to have to resort to hit the database twice to fetch data through the db-relationship. That or resorting to raw SQL. Now, I'll be the first to admit that I just recently got started with django, so my knowledge and/or reasoning about this may be totally off. Also, I'm sorry if this is a FAQ, but I didn't find much about this searching the mailing list archives and the docs on the homepage. Also, if this is something that would be a welcome addition to the codebase (through a specialised QuerySet perhaps), I could probably help out. Regards, Daniel --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
There is an easy way to turn on multi-threading for the default server, see the diff below: Index: basehttp.py === --- basehttp.py (revision 4183) +++ basehttp.py (working copy) @@ -7,10 +7,16 @@ been reviewed for security issues. Don't use it for production use. """ -from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer +from BaseHTTPServer import BaseHTTPRequestHandler from types import ListType, StringType import os, re, sys, time, urllib +import BaseHTTPServer, SocketServer +class HTTPServer(SocketServer.ThreadingMixIn, BaseHTTPServer.HTTPServer): +def __init__(self, server_address, RequestHandlerClass=None): +BaseHTTPServer.HTTPServer.__init__(self, server_address, RequestHandlerClass ) +print '*** MixinHTTPServer ***' + __version__ = "0.1" __all__ = ['WSGIServer','WSGIRequestHandler','demo_app'] --~--~-~--~~~---~--~~ 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 wiki changes
Just a quick note: The Django wiki main page -- http://code.djangoproject.com/wiki -- has been getting out of hand for the past several months, with a massive amount of links and tutorials. Inspired by some wiki spam we got today, I took a moment to move the majority of the page to http://code.djangoproject.com/wiki/DjangoResources and made the main page read-only. That basically means only people with Trac accounts can make changes to the main page. DjangoResources is the place for any and all user-contributed links/documentation. The main wiki page has shifted focus -- and it's generous to say it even *had* a focus -- to being a clean overview. Here's my reasoning behind this. When a visitor to the Django site clicks "Code" in the navigation, he shouldn't see a messy set of links. We should present a clean overview of the "code" aspects of Django -- how to get the code, how to contribute and what we're currently working on. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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?hl=en -~--~~~~--~~--~--~---
Re: Django with CherryPy 3.0
On 1/22/07, Istvan Albert <[EMAIL PROTECTED]> wrote: > There is an easy way to turn on multi-threading for the default server, > see the diff below: Graham and/or anybody else who wants multi-threading in the development server, can you try this patch and see whether it solves your problem? Adrian -- Adrian Holovaty holovaty.com | djangoproject.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?hl=en -~--~~~~--~~--~--~---
Re: Django with CherryPy 3.0
Adrian Holovaty wrote: > Graham and/or anybody else who wants multi-threading in the > development server, can you try this patch and see whether it solves > your problem? I updated my Django trunk with the ThreadingMixIn patch and looking at a couple projects that have media served statically (for development). I think this is proof that it is multi-threaded. Notice how the original request shows up 2nd instead of first: Django version 0.96-pre, using settings 'innovate.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C. [22/Jan/2007 10:15:29] "GET /media/css/style.css HTTP/1.1" 200 6743 [22/Jan/2007 10:15:29] "GET / HTTP/1.1" 200 8014 [22/Jan/2007 10:15:29] "GET /media/css/print.css HTTP/1.1" 200 471 [22/Jan/2007 10:15:29] "GET /media/img/orcas_logo.gif HTTP/1.1" 200 4788 Also, I looked at the Firebug Net view to see how the 4 pieces are loaded. The threaded server shows the 4 pieces with the HTML overlapping the requests for CSS and image. Whereas the default Django never has complete overlap -- requests always finish after the previous one. (I'll attach the images in the next message since I'm in the Google Groups web form right now...) -Rob --~--~-~--~~~---~--~~ 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 wiki changes
Hi, Adrian Holovaty: > [...] I took a moment to move the majority of the page to > http://code.djangoproject.com/wiki/DjangoResources and made the main > page read-only. That basically means only people with Trac accounts > can make changes to the main page. I'm 100 % with you. Is it possible to configure the antispam settings so that taking a lot of links *away* is also considered spam? The point is, currently spammer seems to have found fun in blanking out pages full of links, and then it needs an admin to restore because of the link limit. Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
Adrian Holovaty wrote: > On 1/22/07, Istvan Albert <[EMAIL PROTECTED]> wrote: >> There is an easy way to turn on multi-threading for the default server, >> see the diff below: > > Graham and/or anybody else who wants multi-threading in the > development server, can you try this patch and see whether it solves > your problem? > > Adrian > Yes, it does. I telnet to 8000 to keep a request open, and make a regular browser request. With the current dev server the browser will hang until I kill the telnet. With the patch the browser responds. +1 from me. I'm going to keep the patch on my local checkout and will report if I notice anything funny. Graham --~--~-~--~~~---~--~~ 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 wiki changes
Hi, shouldn't the Reports page be locked down, too? There's already an attachment ... So long, Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company --~--~-~--~~~---~--~~ 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 branch: newforms-admin
On 1/16/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > I'd like to take the clean route and move the admin definitions into a > separate file, or at least still in the models.py but not within the > models themselves. Of course, that's not as convenient as defining the > admin stuff directly within the model, but another solution would > require more typing and possible repetition. ...snip... > We'll have to discuss the tradeoff. It's an interesting conflict > between convenience and purity. If anybody wants to come up with > proposals for syntax, that'd be fantastic. Joseph and I were kicking around some ideas over lunch today, and one thing that seemed like a good idea was moving back to the old-school 'admin as Meta attribute'. Under this scheme, django.contrib.admin would define a default class for model administration. So you could do, say from django.contrib.admin.views import ModelAdmin class MyModel(models.Model): ... fields here ... class Meta: admin = ModelAdmin() And that would get the defaults. Keyword arguments passed to it could control traditional options like list_filter, search_fields, etc. Customization would come form subclassing ModelAdmin (or whatever it ends up being called). The only tricky bit is telling the ModelAdmin instance what model it's administering. I'm thinking maybe a 'model' attribute on the ModelAdmin instance which starts out None, and have the model metaclass go back and set it correctly once the model class exists. Does this sound useful at all? Am I on crack thinking we could go back to admin as a Meta attribute? -- "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?hl=en -~--~~~~--~~--~--~---
Re: admin-interface: move up/down proposal
looks very nice, would also need something like that in a project i am working on. stadtkinowien? :) servus! :D On Dec 19 2006, 5:09 pm, "va:patrick.kranzlmueller" <[EMAIL PROTECTED]> wrote: > we´ve integrated the capability of moving items in the admin change- > list acc. to a field called "position". > > screenshots are here:http://www.vonautomatisch.at/django/move/index.html > > question is: > is someone interested in abstracting the integration, e.g. using some > kind of "move_by"-field in the admin-section of the models. > i can share the files, that´s not the problem. but unfortunately, I´m > currently not capable of doing the move_by-field. > > thanks, > patrick --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
On 1/22/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 1/22/07, Istvan Albert <[EMAIL PROTECTED]> wrote: > > There is an easy way to turn on multi-threading for the default server, > > see the diff below: > > Graham and/or anybody else who wants multi-threading in the > development server, can you try this patch and see whether it solves > your problem? I don't mean to FUD, but introducing threads could be trouble in the runserver. If you're serving multiple requests in response to a single primary view (like dynamic js in response to an html request), if the views aren't thread-safe, stuff will go bad. This isn't an issue if you single-thread in dev and prefork in prod. That said, most of the time, this is good stuff. Perhaps a management option to turn it off? --~--~-~--~~~---~--~~ 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: admin-interface: move up/down proposal
sorry for the delay, here is the code: models.py http://dpaste.com/hold/4898/ views.py http://dpaste.com/hold/4899/ change_list.html http://dpaste.com/hold/4900/ the change_list may look a bit weird (due to the whole js-code and the additional styles). patrick Am 22.01.2007 um 20:28 schrieb stuff4ash: > > looks very nice, would also need something like that in a project i am > working on. > > stadtkinowien? :) servus! :D > > > > On Dec 19 2006, 5:09 pm, "va:patrick.kranzlmueller" > <[EMAIL PROTECTED]> wrote: >> we´ve integrated the capability of moving items in the admin change- >> list acc. to a field called "position". >> >> screenshots are here:http://www.vonautomatisch.at/django/move/ >> index.html >> >> question is: >> is someone interested in abstracting the integration, e.g. using some >> kind of "move_by"-field in the admin-section of the models. >> i can share the files, that´s not the problem. but unfortunately, I´m >> currently not capable of doing the move_by-field. >> >> thanks, >> patrick > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
order of models per app in admin interface
Hi, I've looked in the django code to see if I could get my models ordered explicitly in the admin interface, but could only find code that sorts it alphabetically on name (verbose_name_plural). I hacked up a quick patch that allows you to set an 'order_in_app_models' attribute to the Admin class per model, and it sorts on that if it is found, and falls back to current behaviour if not. Use case: I have three models that should be ordered hierarchically, e.g. Menu > Group > Project. Right now I get Group, Menu, Project which just looks wrong. If some option already exists that gives me this, please enlighten me, otherwise, is there any chance of this patch getting into svn? (I will add doc patches etc. if there's interest) Ciao, Marc. --~--~-~--~~~---~--~~ 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: order of models per app in admin interface
Isn't is easier just to override admin/index.html? That way you can even add some styling/javascript that will organize it to better suit your needs. If you don't know what I mean: 1) copy the file django/contrib/admin/templates/admin/index.html to yourtemplatedir/admin/index.html. 2) Add yourtemplatedir to your TEMPLATE_DIRS tuple in settings.py 3) edit yourtemplatedir/admin/index.html to fit your needs -rob --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
Jeremy Dunck wrote: > That said, most of the time, this is good stuff. Perhaps a management > option to turn it off? My understanding is that no part of basehttp.py is used when Django is deployed via modpython. If that is correct then this addition would make no difference in a production environment. I've researched this mainly because I needed this functionality in the test server, used it for a month or so and it works surprisingly well. I did just for fun a little experiment and it seems to outperform the paste http server as well as cherrypy even under severe load. Potential pitfall: no limit on the number of threads (this could be easily added though), so if you were to use it as a production server (which of course you shouldn't) then you could be DOS'ed simply by having clients connect and not disconnect. Istvan --~--~-~--~~~---~--~~ 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: order of models per app in admin interface
Overriding admin/index.html would make it less generic :-) Instead, I've changed the adminapplist.py templatetag which is used in index.html. It's a very simple patch, really. ..Mc. --~--~-~--~~~---~--~~ 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: admin-interface: move up/down proposal
thx patrick. just noticed you also wrote the filebrowser. very nice work. cheers! ashley On Jan 22, 8:48 pm, "patrick k." <[EMAIL PROTECTED]> wrote: > sorry for the delay, here is the code: > > models.pyhttp://dpaste.com/hold/4898/ > > views.pyhttp://dpaste.com/hold/4899/ > > change_list.htmlhttp://dpaste.com/hold/4900/ > > the change_list may look a bit weird (due to the whole js-code and > the additional styles). > > patrick > > Am 22.01.2007 um 20:28 schrieb stuff4ash: > > > > > looks very nice, would also need something like that in a project i am > > working on. > > > stadtkinowien? :) servus! :D > > > On Dec 19 2006, 5:09 pm, "va:patrick.kranzlmueller" > > <[EMAIL PROTECTED]> wrote: > >> we´ve integrated the capability of moving items in the admin change- > >> list acc. to a field called "position". > > >> screenshots are here:http://www.vonautomatisch.at/django/move/ > >> index.html > > >> question is: > >> is someone interested in abstracting the integration, e.g. using some > >> kind of "move_by"-field in the admin-section of the models. > >> i can share the files, that´s not the problem. but unfortunately, I´m > >> currently not capable of doing the move_by-field. > > >> thanks, > >> patrick --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
On 1/22/07, Istvan Albert <[EMAIL PROTECTED]> wrote: > > Jeremy Dunck wrote: > > > That said, most of the time, this is good stuff. Perhaps a management > > option to turn it off? > > My understanding is that no part of basehttp.py is used when Django is > deployed via modpython. If that is correct then this addition would > make no difference in a production environment. Sorry, I meant that a multi-threaded server in dev could cause ghost problems -in dev- when used to serve code that's not thread-safe. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#2672 - RSS2.0 feed has no support for copyright element
Hi all, Long time listener, first time caller :) I saw ticket #2672 on the LittleEasyImprovements wiki page today and thought it'd be a good opportunity to dip my toes into contributing something back to Django. I have a patch for the relevant modules and documentation updates ready to go, so before I go any further, I have a few questions: 1. Does anyone have any strong opinions on using "copyright" as a keyword argument name, given that there's already a "copyright" in the builtins? I'm currently using feed_copyright and item_copyright (as Atom also supports use of its element at the item level) for feeds and items respectively for this reason. 2. I can't see any existing unit tests for the syndication framework. If I submit a patch without including any testing beyond my claims to have eyeballed the results of using the framework, will I (or someone else) have to write unit tests for the syndication framework before the patch goes anywhere? I still wake up in cold sweats thinking about the sheer variety of tests defined for Mark Pilgrim's feed parser :) Thanks, Jonathan. -- Jonathan Buchanan insin.webfactional.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?hl=en -~--~~~~--~~--~--~---
Re: Django wiki changes
On 22-Jan-07, at 10:56 PM, Adrian Holovaty wrote: > clicks "Code" in the navigation, he shouldn't see a messy set of > links. We should present a clean overview of the "code" aspects of > Django -- how to get the code, how to contribute and what we're > currently working on. looks good - the right way to go -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: New branch: newforms-admin
James Bennett wrote: > Joseph and I were kicking around some ideas over lunch today, and one > thing that seemed like a good idea was moving back to the old-school > 'admin as Meta attribute'. Under this scheme, django.contrib.admin > would define a default class for model administration. This sounds much like what Robert Myers was saying: http://groups.google.com/group/django-developers/browse_thread/thread/d94c7b11392c5085/#7b0f1617e6886ec8 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Admin app not installed properly
Has anyone had a problem with the admin app not displaying correctly? When I log into the admin page, the content is not formatted like all of the pretty examples in the documentation. it is just links and bullets, no field widgets, the filters and tables don't show up correctly, etc. http://www.jasonnolen.com/adminpage.jpg is an example of what I see in the admin page. django.contrib.admin is installed in my settings.py, so that's not the problem. Any ideas? --~--~-~--~~~---~--~~ 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: Admin app not installed properly
seems like you are missing some css files... do you have everything set correctly? On 1/23/07, furby <[EMAIL PROTECTED]> wrote: > > Has anyone had a problem with the admin app not displaying correctly? > When I log into the admin page, the content is not formatted like all > of the pretty examples in the documentation. it is just links and > bullets, no field widgets, the filters and tables don't show up > correctly, etc. > > http://www.jasonnolen.com/adminpage.jpg is an example of what I see in > the admin page. > > django.contrib.admin is installed in my settings.py, so that's not the > problem. > > Any ideas? > > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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 wiki changes
On 1/22/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > shouldn't the Reports page be locked down, too? There's already an > attachment ... Good point. I've locked it down. Thanks! > Is it possible to configure the antispam settings so that taking a > lot of links *away* is also considered spam? The point is, currently > spammer seems to have found fun in blanking out pages full of links, > and then it needs an admin to restore because of the link limit. This is another valid point. Honestly, I don't know if there's a way to configure the antispam functionality to do this. Maybe a Trac expert will enlighten us... Adrian -- Adrian Holovaty holovaty.com | djangoproject.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?hl=en -~--~~~~--~~--~--~---
Re: New branch: newforms-admin
On 1/15/07, Robert Myers <[EMAIL PROTECTED]> wrote: > I would also like to help out. I wanted to fix a few issues with model > validation specifically for admin options. I'm not sure if you plan on > changing any of the existing options or how the options are called though. > If you are then I wont waste my time working on something that will change. > If not, should I? > > A) submit patches against the newforms-admin branch? > B) submit patches for the trunk and wait till branch is merged to see if > they need to be adjusted? Excellent -- I'm excited that you're interested in helping out. The best bet would be to submit patches against the newforms-admin, but I'll give the caveat that I'm moving pretty quickly on this and may duplicate your work. The last thing I want is for you to spend time on a patch, only to have it be made redundant. How about this: Suggest some concrete changes you'd like to make, and I'll try to avoid making those changes. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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?hl=en -~--~~~~--~~--~--~---
Re: New branch: newforms-admin
On 1/22/07, James Bennett <[EMAIL PROTECTED]> wrote: > Joseph and I were kicking around some ideas over lunch today, and one > thing that seemed like a good idea was moving back to the old-school > 'admin as Meta attribute'. Under this scheme, django.contrib.admin > would define a default class for model administration. So you could > do, say > > from django.contrib.admin.views import ModelAdmin > > class MyModel(models.Model): > ... fields here ... > class Meta: > admin = ModelAdmin() So, essentially, it'd act like a model Manager class. The thing I don't like about this approach is that it's still coupled to the model. What if I wanted to have multiple admin interfaces for the same model? (Maybe that's a strawman, but still...) A worthy goal would be to decouple models from admin options completely. The problem (as has been mentioned before) is that we lose a bit of convenience with that approach. > The only tricky bit is telling the ModelAdmin instance what model it's > administering. I'm thinking maybe a 'model' attribute on the > ModelAdmin instance which starts out None, and have the model > metaclass go back and set it correctly once the model class exists. Currently, the ModelAdmin instance gets passed its model in __init__(), by the admin views. That's kind of nice because it means you can reuse a given ModelAdmin subclass for multiple models. It'd be fantastic if we came up with a solution that maintained this decoupling -- i.e., a ModelAdmin class doesn't know its model. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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?hl=en -~--~~~~--~~--~--~---
Re: New branch: newforms-admin
Adrian Holovaty wrote: > I'd like to take the clean route and move the admin definitions into a > separate file, or at least still in the models.py but not within the > models themselves. Of course, that's not as convenient as defining the > admin stuff directly within the model, but another solution would > require more typing and possible repetition. I'm +1 on this. I like the idea of having a separate "admin.py" file or something. Will. --~--~-~--~~~---~--~~ 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: specifying newforms-admin options
Lachlan Cannon wrote: > It feels right to me to have admin and the model separate. The way I think of > it > is this: Suppose I distribute an app and a user decides to use the app, but > doesn't run the auto-admin. With my admin information factored out in a > separate > file: admin.py, she's not loading code that she'll never use. > > It also makes it feel like admin is just another (albeit kickarse) Django app, > just like any other. It's not magically intertwined with model classes unlike > other apps. I'd like to second this notion. +1. Will. --~--~-~--~~~---~--~~ 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: Disable field creation in forms for hidden model fields (#3247)
On 1/18/07, Philipp Keller <[EMAIL PROTECTED]> wrote: > I think it's quite important to have the opportunity to say "I don't want > this field to appear in any of my forms" but on the other hand, you may want > to suppress this fields in the admin. > > I think if I wouldn't know anything of django and would look at > editable=False in the model, I'd think it would affect all forms, not just > the admin forms. > For the admin, the settings usually go into the admin-metaclass. In fact > there is a setting in the admin metaclass to control the fieldSETs but not > the appearing fields. > > I can think of two possible solutions: > > a) have an extra parameter editable_admin=False (although this is quite ugly > and isn't backwards compatible) > b) have a new admin metaclass "option" in the form of > class Admin: > editable = [list of all fields to show up in admin] Here's an idea that's a bit cleaner, thanks to the newforms-admin branch... In that branch, the Admin options class has a new hook, formfield_for_dbfield(). This takes a database Field instance and returns the newforms Field instance, so you can use it to implement admin-specific editable stuff: def formfield_for_dbfield(self, db_field, **kwargs): if db_field.name == 'my_uneditable_field': return None # No form field return super(MyAdminClass, self).formfield_for_dbfield(db_field, **kwargs) The remaining question, then, is whether form_for_model should *not* create formfields for database fields with editable=False. Judging by people's comments in this thread, it seems like that's a no-brainer -- if editable=False, then the form_for_model form should not include the field. If there aren't any other thoughts on this, let's go ahead and update the ticket using our slick new triage process. :-) Adrian -- Adrian Holovaty holovaty.com | djangoproject.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?hl=en -~--~~~~--~~--~--~---
Critical ticket: can cause data loss
Deletion of objects with a GenericRelation(X) deletes unrelated X objects with the same object_id! http://code.djangoproject.com/ticket/3215 This ticket needs developers focus sooner rather than later. The implications of this patch mean it's not acceptable for this patch to sit in the queue - it needs to be fast-tracked. (excuse me if this is a duplicate post, the other one seems to have disappeared / was never posted correctly) --~--~-~--~~~---~--~~ 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: Admin app not installed properly
On 23-Jan-07, at 8:02 AM, furby wrote: > django.contrib.admin is installed in my settings.py, so that's not the > problem. it cant find the css - check the document source to see where it is looking for the css and make sure that is correct in relation to your setup -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Critical ticket: can cause data loss
On 1/22/07, SmileyChris <[EMAIL PROTECTED]> wrote: > Deletion of objects with a GenericRelation(X) deletes unrelated X > objects with the same object_id! > http://code.djangoproject.com/ticket/3215 > > This ticket needs developers focus sooner rather than later. The > implications of this patch mean it's not acceptable for this patch to > sit in the queue - it needs to be fast-tracked. Could somebody provide some unit tests that isolate the problem? I've never mucked with the GenericForeignKey code -- perhaps Jacob or Russell could chime in here for the fix? Adrian -- Adrian Holovaty holovaty.com | djangoproject.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?hl=en -~--~~~~--~~--~--~---
Re: Critical ticket: can cause data loss
On 1/23/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Could somebody provide some unit tests that isolate the problem? I've > never mucked with the GenericForeignKey code -- perhaps Jacob or > Russell could chime in here for the fix? I've never really played with GenericRelations, so I don't know their internals particularly well. I'll have a look tonight and see if I can make any sense of the problem. 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?hl=en -~--~~~~--~~--~--~---
Re: trac: please bring back 'reopen'
SmileyChris wrote: > On Jan 19, 2:29 am, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > > (At least, I cannot reopen from closed/invalid) > > Very interesting - it looks like that action is being hidden from > > non-authenticated users... I'll investigate. > > How's the investigation going? I'm apprehensive of closing tickets > requiring more info until this gets fixed. Reopening a ticket should probably also set the triage stage back to unreviewed. Until this is resolved, I suggest to add a keyword of "reopen" to tickets to that need reopening, which then could be found with: http://code.djangoproject.com/query?status=closed&keywords=%7Ereopen&order=priority I was going to add this to the report page, but it seems like the page has been locked down. --~--~-~--~~~---~--~~ 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 wiki changes
Is it possible to just block attachments on the pages completely? I know that there are valid ones out there, but the vast majority seem to be spam (& because it's not apparent how attachements can be removed from the wiki, they just sit there forever). Anyway - while we're talking about the wiki, #1850 suggests an "incubator" for Django projects: http://code.djangoproject.com/ticket/1850 This is a good idea, but would take a lot to set up. Has anyone got any ideas/suggestions for an easily implemented wiki-style solution for this? -Simon G. --~--~-~--~~~---~--~~ 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: trac: please bring back 'reopen'
Hi, Gary Wilson schrieb: > SmileyChris wrote: >> On Jan 19, 2:29 am, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: (At least, I cannot reopen from closed/invalid) >>> Very interesting - it looks like that action is being hidden from >>> non-authenticated users... I'll investigate. >> How's the investigation going? I'm apprehensive of closing tickets >> requiring more info until this gets fixed. > > Reopening a ticket should probably also set the triage stage back to > unreviewed. Hmm, I usually have an eye on the timeline and will have a look on changes that modify the stage. > Until this is resolved, I suggest to add a keyword of "reopen" to > tickets to that need reopening, which then could be found with: > http://code.djangoproject.com/query?status=closed&keywords=%7Ereopen&order=priority That's a good idea! > I was going to add this to the report page, but it seems like the page > has been locked down. Some playkid has already made attachements, so this was made sense. 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?hl=en -~--~~~~--~~--~--~---
