Hi Adrian. Super :-) This did the trick. Many thanks!
Regards
David
Adrian Holovaty wrote:
On 12/15/05, David Pratt <[EMAIL PROTECTED]> wrote:
Can someone fill in the blank. Many thanks.
[...]
from django.core import management
# Setup up an app
management.init()
management.install(my_app
On 12/15/05, David Pratt <[EMAIL PROTECTED]> wrote:
> Can someone fill in the blank. Many thanks.
> [...]
> from django.core import management
>
> # Setup up an app
> management.init()
> management.install(my_app)
>
> # Admin install ???
Hi David,
You want this:
from django.core import meta
Hi. Have a quick question. I have been programatically setting up my
databases with default data etc, and install by importing management.
Trouble is I cannot seem to find method equivalent to:
django-admin.py install admin
so I can do this at the same time. Can someone fill in the blank. Ma
On 12/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Currently, the core handlers (modpython.py and wsgi.py in
> django/core/handlers/) wrap the main request handling in a
> try/finally, where the "finally" part closes the database connection.
> Obviously, this couples the handler to a data
Can the admin options be specified in the meta.Manager field?
e.g.
class Whatever(Model):
name = CharField(maxlength=100)
objects = Manager(list_display=)
-rob
Currently, the core handlers (modpython.py and wsgi.py in
django/core/handlers/) wrap the main request handling in a
try/finally, where the "finally" part closes the database connection.
Obviously, this couples the handler to a database connection, which is
not ideal, because people should be able
On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> Basically, promote Admin settings to a full inner class, rather than
> nesting it in meta. It would still end up in meta though.
+1; the improvement in readability would be welcome. The Admin
declarations are too visually messy at the mo
On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Basically, promote Admin settings to a full inner class, rather than
> nesting it in meta. It would still end up in meta though.
I could go either way on this. But if we create the ADMIN thing, maybe
it's a good opportunity to move some of
As we are regularising the model syntax, here is a question,
Should
class Whatever(meta.Model):
name = meta.CharField(maxlength=100)
class META:
admin = meta.Admin(
list_display = ('username', 'email',
'first_name','last_name', 'is_sta
Sure. There may not be a need for a "project" dir when you have only
one project running. It is cleaner to simply have /admin/blog/entry/add
or even /admin/entry/add. Also, you may want your model to technically
describe the object accurately, but present it to the user in a more
readable way, or
oggie rob wrote:
> Would it be possible to override the url location within the
> modules/classes? My only concern is that sometimes the project, module
> and/or class name are not an appropriate part of a URL, and would be
> nice to easily override. (This of course assumes that URLs are part of
>
Would it be possible to override the url location within the
modules/classes? My only concern is that sometimes the project, module
and/or class name are not an appropriate part of a URL, and would be
nice to easily override. (This of course assumes that URLs are part of
the UI, which I feel is tr
On 12/14/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/
+1
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
>Or substitute slashes for dots:
>
> /admin/myproject/blog/models/entry/add/
I like this better. Slashes are better than dots.
Thanks,
Eugene
I think Cherry is more instance-y, Quixote was more package-based but
with v.2 is now more explicit with "Directory" classes that define
traversals. I think. I don't use either in real life.
Just thought I'd mention them as references that might be applicable --
even if they're too much for this
ToddG wrote:
> I don't know if there's a mathematical formula for this, but it's
> looking like all ideas are approaching an object traversal/resolution
> scenario like in: Zope, Quixote, CherryPy, etc. Perhaps one of those
> can offer some direction.
>
>
I think most of those work on an instan
I don't know if there's a mathematical formula for this, but it's
looking like all ideas are approaching an object traversal/resolution
scenario like in: Zope, Quixote, CherryPy, etc. Perhaps one of those
can offer some direction.
On Dec 14, 2005, at 9:15 PM, Adrian Holovaty wrote:
Or maybe get rid of the "models" cruft:
/admin/myproject/blog/entry/add/
This one's my favorite.
Double points if /admin/myproject/ shows a list of models under
myproject (and /myproject/blog/ shows all the ones under
myproject.blo
Adrian Holovaty wrote:
> In the magic-removal branch (see
> http://code.djangoproject.com/wiki/RemovingTheMagic), we're removing
> the magic model modules, which means the concept of "module_name" goes
> away. This creates a bunch of interesting new issues, because some
> parts in Django use modul
19 matches
Mail list logo
