On 1/20/07, CosyGlow <[EMAIL PROTECTED]> wrote:
> Any advice on this one, please?
Pop open a Python shell.
Do
>>> import sys
>>> sys.path
And make sure the parent directory of your project appears there. If
not, add that to your Python path.
If it does appear there, verify that your project a
Simon
Thanks for the advice, I'd tried your advice and it worked with no
error messages (Ps. I've tried it before and it also worked), but the
underlying reason why I'd tried the "django-admin.py runserver" is
because I'm getting "Could not import mysite.accdetls.views. Error was
: cannot import
We should have a "security-log" on the wiki (although editing would be
locked to core-devs only), which lists any found vulnerabilities, when
they were patched and what versions were affected, and a
best-course-of-action e.g.:
Vulnerability:
Date Discovered: <...>
Potential Risk:
Brief Descript
Morning all,
I have a question regarding oldforms - are these
end-of-line/deprecated? That is, are we still taking enhancement
requests/patches for these? My vote, FWIW, is -1, but they should be
checked to make sure that newforms doesn't make the same mistakes.
These are the ones I've found so
On 1/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/20/07, Robert Myers <[EMAIL PROTECTED]> wrote:
> > However, my latest brainstorm idea is to place an admin-urls.py
> > file in each app which would work just like the generic views and allow you
> > to specify nearly everything. The de
James Bennett wrote:
> I like having a bugfixes branch for each major release, because we're
> already committed to providing legacy support for current + two
> previous releases, and so the bugfixes branch becomes a natural place
> to do that work. Since we'd be creating it eventually anyway, we
On 1/20/07, Robert Myers <[EMAIL PROTECTED]> wrote:
> However, my latest brainstorm idea is to place an admin-urls.py
> file in each app which would work just like the generic views and allow you
> to specify nearly everything. The defaults of course would be the standard
> options or urls in the
I agree that moving this out of the model would be a great idea. I have been
thinking about this for a long time and not quite sure the best way to
handle it. However, my latest brainstorm idea is to place an
admin-urls.pyfile in each app which would work just like the generic
views and allow you
t
Just an extra vote for this.
I I think it's probably neatest to have the option of an editable
parameter in the Admin class, which overrides any model settings.
Perhaps:
class Admin:
editable = {'field1': True, 'field2': False}
--~--~-~--~~~---~--~~
You receiv
Hi all,
I am trying to start a discussion about #1541
http://code.djangoproject.com/ticket/1541
Some discussion about this bug can be seen here
http://groups.google.com/group/django-developers/browse_thread/thread/9f9f1ff61e9314a5/aa9fac2811918961
This is a proposal and patch to add multipart m
I'd also be interested in looking at the files as as we were considering
implementing this for a project we're working on. Maybe instead, we can
take the time to abstract this into a field.
Lakin
On 12/19/06, Chad Maine <[EMAIL PROTECTED]> wrote:
>
> I've built similar things in django myself, a
Congrats, James! Nobody better for the job, says I :)
--~--~-~--~~~---~--~~
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
Have you already decided on a simple, fast, non-deprecated, standard way of
extending the User model?
Last I remember, a ForeignKey(unique=True) was recommended, but that was
kind of a hack due to the deprecation of the OneToOneField.
j
--~--~-~--~~~---~--~~
You re
Adrian Holovaty wrote:
> But the bigger question is, should the "class Admin" even live in the
> model at all, given that it's gaining many more hooks, not all of
> which are simple data structures. With each hook I add, it feels more
> and more messy to have that functionality within the model. O
When Django creates a project, it'll make a file called "manage.py" and
"settings.py" in the top level directory of that project. That settings
file is what it's after, and manage.py will automatically use that one.
So - try this instead:
python manage.py runserver
Hope this helps,
-Simon G.
Hi
I'm getting the following error when running the "DJANGO-ADMIN.PY
RUNSERVER" command. I've checked every possible link and followed every
instruction written in the django online documentation, but without
luck.
The error message is : "raise EnvironmentError, "Could not import
settings '%s'
16 matches
Mail list logo
