Re: ORM funkiness when doing Many2Many to intermediary table with the same source table twice
antrod, > If I've got a Many2Many relationship implemented via an intermediary > table (a la > http://www.djangoproject.com/documentation/models/m2m_intermediary/) > but in the intermediary table I point back to the same table twice, > does django's ORM not support this? > > Example: table Node, intermediary table Relationship that wants to > point back to Node twice (once as attribute 'child' and once as > attribute 'parent'). It seems like what I get is the ability to see > just one of the references back (the first one declared in the model > object), so with a call like > Node.get_relationship_list(parent__id__exact=x) I get nothing even if > it is there. It is supported, but badly documented. You have to use the 'singular' attribute when defining the ManyToMany field. Some docs are on this page: http://code.djangoproject.com/wiki/ModelSyntaxChangeInstructions Luke -- "Idiocy: Never underestimate the power of stupid people in large groups." (despair.com) Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
import error
I'm trying to import a simple utils.py from the toplevel of my application, i.e. from ttime.utils import * All I get from djangoadmin.py runserver is: "ImportError: No module named utils". The utils.py is there, but the django server can't seem to find it, I suspect this is a true newbie question: what's the best way to add simple utility functions usable for all modules to my django app? R /LarS
Re: Pb with Backwards-incompatible admin changes
On 10/20/05, Laurent RAHUEL <[EMAIL PROTECTED]> wrote: > THX, it was the problem. I guess this should be added to the documentation. I've updated the docs at http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges . Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Re: Pb with Backwards-incompatible admin changes
Le Jeudi 20 Octobre 2005 17:44, Andreas Stuhlmüller a écrit : > Hi Laurent, > > > Error: The database couldn't be initialized. > > 'module' object has no attribute 'INSTALLED_APPS' > > Deleting your project/settings directory might help. At least it helped > when I got this error :). > > Andreas THX, it was the problem. I guess this should be added to the documentation.
Re: Pb with Backwards-incompatible admin changes
Hi Laurent, > Error: The database couldn't be initialized. > 'module' object has no attribute 'INSTALLED_APPS' Deleting your project/settings directory might help. At least it helped when I got this error :). Andreas
Pb with Backwards-incompatible admin changes
Hi, I'm trying to move my code after those changes and I can't get python django-admin.py init working. I get this error and I can't figure out why : Error: The database couldn't be initialized. 'module' object has no attribute 'INSTALLED_APPS' I got a good PYTHONPATH and a good DJANGO_SETTINGS_MODULE environment variables. I read the documentation for upgrading after admin changes and I hope I did everything well. Any idea ?? Regards, Laurent.
Error in myapp
Hello! Wrote polls app from tutorial and it was worked, then write articles app and see this error: File "/home/greg/www/django_src/django/core/urlresolvers.py", line 77, in _get_urlconf_moduleself._urlconf_module = __import__(self.urlconf_name, '', '', ['']) ImportError: No module named urls now and polls app give the same error. Why? -- Всего наилучшего! greg [at] anastasia [dot] ru Григорий.
Re: Do's and Dont's for Application Writers
On 10/20/05, Robert Wittams <[EMAIL PROTECTED]> wrote: > Should I add this to the wiki page? Feel free. But, please don't use @decorator syntax, it's not 2.3-safe. /s
ORM funkiness when doing Many2Many to intermediary table with the same source table twice
If I've got a Many2Many relationship implemented via an intermediary table (a la http://www.djangoproject.com/documentation/models/m2m_intermediary/) but in the intermediary table I point back to the same table twice, does django's ORM not support this? Example: table Node, intermediary table Relationship that wants to point back to Node twice (once as attribute 'child' and once as attribute 'parent'). It seems like what I get is the ability to see just one of the references back (the first one declared in the model object), so with a call like Node.get_relationship_list(parent__id__exact=x) I get nothing even if it is there. Thx AR
Re: Do's and Dont's for Application Writers
On 10/20/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> * All app templates assume there's a "base_generic" template and {%
> extend %} it.
> * All app templates assume the is in {% title %}.
> * All app templates assume there's a {% block extrahead %} within the
> . This is a hook for putting arbitrary things in .
> * All app templates assume the parent templates have defined {% block
> content %}, for the main content area of the page.
I like that very much, except for one little nitpick. Is there any reason
for using underscores instead of dashes? A dash is so much is easier
to type.
I'll fold it into Do's and Dont's.
> I'd even go so far as to say we could include the above base.html and
> base_generic.html in the Django distribution proper, to give people a
> starting point when creating their templates.
In project_template/templates/?
And maybe app_template/templates/base.html which just extends
base_generic?
/s
Re: Do's and Dont's for Application Writers
On 10/20/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > I had this same question: What's a mnemosyne? We should change it to "myapp". Mnemosyne is the greek goddess of memory, I pulled it out of the hat, because I think myapp is so boring and impersonal. But, feel free to change it. /s
Re: Error in DateFormat
Hello Adrian Holovaty! On Thu, 20 Oct 2005 08:46:47 -0500 you wrote: > Fixed as of revision 976. > > Adrian Thanks, very much! -- Всего наилучшего! greg [at] anastasia [dot] ru Григорий.
Re: Error in DateFormat
On 10/20/05, Grigory Fateyev <[EMAIL PROTECTED]> wrote: > Install blogs app from django_website, and when whant to see comment of > blog entrie see this error: > > File "/home/greg/www/django_src/django/utils/dateformat.py", line 26, > in formatpieces.append(str(getattr(self, piece)())) > > AttributeError: DateFormat instance has no attribute 'P' Fixed as of revision 976. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Re: Do's and Dont's for Application Writers
On 10/20/05, kmh <[EMAIL PROTECTED]> wrote:
> Seeing it in writing got me wondering though if the whole idea of
> application templates "extending" the base site is wrong-headed.
> Because the application knows nothing about the site it is to be
> embedded in, the application writer is second-guessing what base
> template it is supposed to extend. Say the 'blog' and 'gallery'
> applications need to appear on the same page in different
> columns...what then?
The way we've done things for the past 2 years at World Online, with
dozens of decoupled Django apps, is to have a standard convention for
templates. Here's a short explanation of the convention, which I think
we should promote:
* All app templates assume there's a "base_generic" template and {%
extend %} it.
* All app templates assume the is in {% title %}.
* All app templates assume there's a {% block extrahead %} within the
. This is a hook for putting arbitrary things in .
* All app templates assume the parent templates have defined {% block
content %}, for the main content area of the page.
Essentially, the convention is to assume these base templates:
base.html:
"""
{% block title %}{% endblock %}
{% block extrahead %}{% endblock %}
{% block content %}{% endblock %}
"""
base_generic.html
"""
{% extends "base" %}
"""
Solidifying a convention like this would go a long way in making
Django apps easily pluggable (via their default templates). Of course,
it shouldn't (and won't) be required that app users *use* the default
templates that come with an app -- they're just a quick starting point
and serve as documentation.
I'd even go so far as to say we could include the above base.html and
base_generic.html in the Django distribution proper, to give people a
starting point when creating their templates.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
Re: Do's and Dont's for Application Writers
On 10/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > great start. just two comments. why use mnemosyne as the example? why > not something more generic like "myapp" ? I had this same question: What's a mnemosyne? We should change it to "myapp". Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Error in DateFormat
Hello! Install blogs app from django_website, and when whant to see comment of blog entrie see this error: File "/home/greg/www/django_src/django/utils/dateformat.py", line 26, in formatpieces.append(str(getattr(self, piece)())) AttributeError: DateFormat instance has no attribute 'P' -- Всего наилучшего! greg [at] anastasia [dot] ru Григорий.
Re: Do's and Dont's for Application Writers
kmh wrote:
>>On 10/20/05, kmh <[EMAIL PROTECTED]> wrote:
>>
>>>Shouldn't we encourage a model where site templates are able to
>>>explicitly "include" application templates, rather than the other way
>>>around?
>
>
>>On 10/20/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
>>That's not how applications and templates work. You can't just
>>include a template from another application, you would be missing
>>the context that the application views provide.
>
>
> A more "include" oriented solution would be to let sites rather than
> applications determine which site base template is being extended by an
> application template. I have just discovered the {% extends variable
> %} tag, which seems to fit this bill. It should also be encouraged
> that application features that don't depend on the request be made
> templates tags rather than views.
>
> Kieran
>
>
I think what you actually want is for applications to provide you with
template tags that encapsulate most of the functionality of thier views.
Then in your site template, you can compose these template tags to your
hearts content.
Maybe this should be a best practice too?
This is very easy with the @inclusion_tag decorator in #625.
(Predicated on 625 being applied (cough...Adrian...cough) , or using
new-admin branch.)
Should I add this to the wiki page?
-
Parts of your application that may be useful embedded in site views
should be structured as template tags.
Create a template of just the portion of your view that is reusable:
poll/results_panel.html:
{{poll.name}}
{%for choice in poll%}
{{ choice}} : {{choice.votes}}
{%end for%}
create a template tag using this template,
polls/templatetags/polls.py
@inclusion_tag('poll/results_panel.html')
def results_panel(poll):
return {'poll': poll}
In your views and site views, use the template tag:
{% load polls %}
{% results_panel poll %}
Sites can override the poll/results_panel.html template to customise
this. It will apply sitewide, including within the app within which the
template tag resides.
(It is of course possible to do this without using @inclusion_tag, but
it is a pain.)
---
This seems like a pretty good pattern to me, especially for apps to
provide little summary views for aggregation by sites.
Re: site url
On Thursday 20 Oct 2005 4:56 pm, Andy Shaw wrote:
> > {{ site_url }}/css/layout.css.
> > how do i do this?
>
> Um... I don't know the actual answer to your question off the bat,
> but you can use an absolute URI that doesn't contain the site name:
thing is that i have one copy of the app on my local machine and the
other on the production server. if this is portable i can test out on
my local machine and then just update on the server without changing
anything. The only difference between the two is the
'http://localhost/' part
--
regards
kg
http://www.livejournal.com/users/lawgon
tally ho! http://avsap.org.in
ಇಂಡ್ಲಿನಕ್ಸ வாழ்க!
Re: Do's and Dont's for Application Writers
On 10/20/05, kmh <[EMAIL PROTECTED]> wrote: > >On 10/20/05, kmh <[EMAIL PROTECTED]> wrote: > >> Shouldn't we encourage a model where site templates are able to > >> explicitly "include" application templates, rather than the other way > >> around? > > >On 10/20/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote: > >That's not how applications and templates work. You can't just > >include a template from another application, you would be missing > >the context that the application views provide. > > A more "include" oriented solution would be to let sites rather than > applications determine which site base template is being extended by an > application template. If a site wants different application-templates to extend different base-templates, they should override the application-templates. Most sites won't need that kind of over engineering mojo, so we should not burden sites or applications with it. And, for some applications it's even downright troublesome. For example, ibofobi.apps.blog has a blog/base template, which all the other templates extends. The blog/base template makes sure all the blog pages contain a common footer and have the blog-name in the title. Duplicating the title and footer in all the other templates would be silly. > It should also be encouraged > that application features that don't depend on the request be made > templates tags rather than views. Yes, definetly. I've put that in. /s
Re: Do's and Dont's for Application Writers
>On 10/20/05, kmh <[EMAIL PROTECTED]> wrote:
>> Shouldn't we encourage a model where site templates are able to
>> explicitly "include" application templates, rather than the other way
>> around?
>On 10/20/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
>That's not how applications and templates work. You can't just
>include a template from another application, you would be missing
>the context that the application views provide.
A more "include" oriented solution would be to let sites rather than
applications determine which site base template is being extended by an
application template. I have just discovered the {% extends variable
%} tag, which seems to fit this bill. It should also be encouraged
that application features that don't depend on the request be made
templates tags rather than views.
Kieran
Re: site url
Kenneth Gonsalves wrote:
hi,
i know it must be somewhere, but cant find it. How do you refer to the
site url in a template? Say my css file is in
http://mysite.com/css/layout.css, to make this portable i would have to
make the template as:
{{ site_url }}/css/layout.css.
how do i do this?
Um... I don't know the actual answer to your question off the bat, but
you can use an absolute URI that doesn't contain the site name:
Works for me...
-Andy
Re: Do's and Dont's for Application Writers
On 10/20/05, kmh <[EMAIL PROTECTED]> wrote: > Shouldn't we encourage a model where site templates are able to > explicitly "include" application templates, rather than the other way > around? That's not how applications and templates work. You can't just include a template from another application, you would be missing the context that the application views provide. > Say the 'blog' and 'gallery' > applications need to appear on the same page in different > columns...what then? Then you would have to write a site-specific view and template, because neither the blog or gallery application can have a view for that (since they don't know of the other.) /s
Re: Do's and Dont's for Application Writers
Hey, great start. just two comments. why use mnemosyne as the example? why not something more generic like "myapp" ? for the media directory, mnemosyne/media/ should be sufficient.
Re: Tag library not found
Works a treat, thanks! Wonder if you've had a chance to take a look at this: http://code.djangoproject.com/ticket/480#preview Still seems to be bothering me... Thanks, Tom
Re: Do's and Dont's for Application Writers
Hi Sune, Thanks for getting this thread going. Your outline is pretty close to the way I've been doing things too. Seeing it in writing got me wondering though if the whole idea of application templates "extending" the base site is wrong-headed. Because the application knows nothing about the site it is to be embedded in, the application writer is second-guessing what base template it is supposed to extend. Say the 'blog' and 'gallery' applications need to appear on the same page in different columns...what then? Shouldn't we encourage a model where site templates are able to explicitly "include" application templates, rather than the other way around? Though I haven't used it, the 'ssi' tag looks like the kind of thing I have in mind. Kieran
site url
hi,
i know it must be somewhere, but cant find it. How do you refer to the
site url in a template? Say my css file is in
http://mysite.com/css/layout.css, to make this portable i would have to
make the template as:
{{ site_url }}/css/layout.css.
how do i do this?
--
regards
kg
http://www.livejournal.com/users/lawgon
tally ho! http://avsap.org.in
ಇಂಡ್ಲಿನಕ್ಸ வாழ்க!
Do's and Dont's for Application Writers
Hullo. Here is a rough draft of "Do's and Dont's for Application Writers": http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters I'd be much interested in comments, suggestions and anything people disagree with, but can we keep feedback on the list? Wikis have horrible threading ;) /s
Re: dynamic choices
stava wrote:
> I'm having a bit of a problem with dynamic choices. I'm working on a
> simple timesheet system where I've extended the auth.users with a
> couple of fields including something I call "primary group":
>
> def getUsers(group = None):
> users = []
> if group is None:
> for u in auth.users.get_values(fields = ('id', 'username',)):
> users.append((u['id'], u['username']))
> else:
> for u in auth.users.get_values(
> fields = ('id', 'username',),
> tables = ['auth_users_groups', 'auth_groups'],
> where = ["auth_groups.name = '%s'" % group,
> 'auth_users_groups.group_id = auth_groups.id',
> 'auth_users_groups.user_id = auth_users.id']):
> users.append((u['id'], u['username']))
> return users
>
> class Department(meta.Model):
> department = meta.CharField(maxlength = 10, unique = True,
> help_text = 'Short name')
> name = meta.CharField(maxlength = 30, unique = True,
> help_text = 'Full name')
> costcentre = meta.CharField(maxlength = 10)
> manager= meta.ForeignKey(auth.User, verbose_name = 'manager',
> choices = getUsers('Line Manager'),
> help_text = 'Department manager')
>
> class User(auth.User):
> primary_group = meta.ForeignKey(auth.Group, default = 1,
> verbose_name = 'primary group')
> department= meta.ForeignKey(Department, default = 1)
> country = meta.ForeignKey(Country, default = 1,
> help_text = 'Country the user belongs to')
> notes = meta.TextField(blank = True)
>
> Now comes the problem, and I can't decide if it's a bug or if I am not
> using 'choices' the right way: when initialising a freshly created
> database, I get:
>
> django-admin init tttime
> Error: The database couldn't be initialized.
> (1146, "Table 'tttime.auth_users' doesn't exist")
>
> However, if I comment out the 'choices' part of the 'manager'
> definition in the Department class, it works like a charm. Then I can
> uncomment the 'choices' and everything works as expected.
>
> Please advice anyone? Is there a better way to implement dynamic
> choices?
>
> /stava
And, of course, if one were to read the documentation properly:| the
solution is to use 'limit_choices_to'.
/stava
