Pluggable application template customization
Hi, We have developed Telemeta, a "pluggable" Django application (to be added to INSTALLED_APPS). It works great. We now need to support per-project templates customization as one can do for the admin. Telemeta provides a bunch of default templates. Once one has created a new django project, and installed telemeta, there is a need to customize the templates for this particular project. So, as it's done for the admin in my_project/templates/admin, I would like to make it possible to create a my_project/templates/telemeta directory and put customized templates in there, overloading default templates. How can I add support for this optional templates/telemeta directory, automatically, whenever one has installed telemeta ? Regards, -- Olivier Guilyardi / Samalyse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Pluggable application template customization
Malcolm Tredinnick wrote:
> On Fri, 2009-01-09 at 14:00 +0100, Olivier Guilyardi wrote:
>> Hi,
>>
>> We have developed Telemeta, a "pluggable" Django application (to be added to
>> INSTALLED_APPS). It works great. We now need to support per-project templates
>> customization as one can do for the admin.
>>
>> Telemeta provides a bunch of default templates. Once one has created a new
>> django project, and installed telemeta, there is a need to customize the
>> templates for this particular project.
>>
>> So, as it's done for the admin in my_project/templates/admin, I would like to
>> make it possible to create a my_project/templates/telemeta directory and put
>> customized templates in there, overloading default templates.
>>
>> How can I add support for this optional templates/telemeta directory,
>> automatically, whenever one has installed telemeta ?
>
> The telemeta source would need to support this directly, by passing a
> list of template names to render_to_response() (not just a single
> template name). Have a look at the usage of render_to_response() in
> django/contrib/admin/options.py, for example.
>
> Alternatively, it could use select_template() as documented in [1].
> Particularly, see the "Tip" in that piece of documentation. That
> describes the method used.
>
> [1]
> http://docs.djangoproject.com/en/dev/ref/templates/api/#the-python-api
Thanks for this pointer. But I actually didn't read, or forgot, the very next
sentence after this tip: "It's possible -- and preferable -- to organize
templates in subdirectories of the template directory. The convention is to make
a subdirectory for each Django app, with subdirectories within those
subdirectories as needed.".
This is exactly how it's done for the admin, the templates reside in
django/contrib/admin/templates/admin and not in django/contrib/admin/templates.
So I've moved all of telemeta templates from telemeta_app/templates into
telemeta_app/templates/telemeta, which looks cleaner to me, to avoid conflict
with templates from the project or other apps.
But when I add a customized template into my_project/templates/telemeta, the
customizations are invisible. I must add that the default template I'm trying to
overload is itself extending another template. So maybe that this problem
relates to the extend functionality ? For instance, in the admin, this seems
addressed in:
http://code.djangoproject.com/browser/django/tags/releases/1.0.2/django/contrib/admin/views/template.py#L56
Should I replace the "extends" tag as well ?
You can read the telemeta template that I'm trying to extend here:
http://telemeta.org/browser/trunk/telemeta/templates/telemeta/mediaitem_detail.html?rev=335
Regarding render_to_response() with multiple templates or select_template(), by
reading admin's options.py it looks to me like this shouldn't be necessary. By
using render_to_response('telemeta/mediaitem_detail.html') the template loader
should automatically look for
my_project/templates/telemeta/mediaitem_detail.html and then for
telemeta_app/templates/telemeta/mediaitem_detail.html. Am I wrong ?
> Since the Telemeta website seems to be crashing at the moment, I can't
> see if they're set up to support that or not, but a quick search through
> the source should reveal the details.
This is only a random crash, which we're in the process of fixing. Please click
reload, it should work ok.
--
Olivier Guilyardi / Samalyse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Pluggable application template customization
Olivier Guilyardi wrote:
> Malcolm Tredinnick wrote:
>> On Fri, 2009-01-09 at 14:00 +0100, Olivier Guilyardi wrote:
>>>
>>> How can I add support for this optional templates/telemeta directory,
>>> automatically, whenever one has installed telemeta ?
>> The telemeta source would need to support this directly, by passing a
>> list of template names to render_to_response() (not just a single
>> template name). Have a look at the usage of render_to_response() in
>> django/contrib/admin/options.py, for example.
>>
>> Alternatively, it could use select_template() as documented in [1].
>> Particularly, see the "Tip" in that piece of documentation. That
>> describes the method used.
>>
> Regarding render_to_response() with multiple templates or select_template(),
> by
> reading admin's options.py it looks to me like this shouldn't be necessary. By
> using render_to_response('telemeta/mediaitem_detail.html') the template loader
> should automatically look for
> my_project/templates/telemeta/mediaitem_detail.html and then for
> telemeta_app/templates/telemeta/mediaitem_detail.html. Am I wrong ?
I forgot to configure TEMPLATE_DIRS in my_project. It works ok now. Sorry for
the noise.
Thanks
--
Olivier Guilyardi / Samalyse
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Design question: Persistent / non-transactional process & django
[EMAIL PROTECTED] wrote: > If we want to make a persistent TCP connection with a data queue, is > django the best place (or even a possible place) for this connection > layer to live? I see these options: In a production environment, you need Django to run on Apache, so I think you can't expect anything to be persistent at the application level. > > 1) Write a separate TCP daemon app which accepts the input from django > and maintains a permanent connection to the remote proprietary > service. (Which IPC mechanism would work best is another question: > using a database table as a queue? Using a unix socket and a memory > queue on the daemon?) The problem with a daemon, is that, in the long run, it may crash or become unresponsive for various reasons. > 2) Find somewhere in django where I can create a persistent queue, > have the http transaction write to the queue and have a django service > persistently checking the queue while maintaining the outbound TCP > connection. This is where I am especially short on technical > knowledge. Is there any way to have code running persistently in the > django environment that starts when the web server is started, or is > everything entirely event driven? Correct me if I'm wrong, but to my understanding Django operates as a normal web application framework upon Apache, and so yes it is entirely "event driven". Running some code persistently, if possible, is going to be complicated, and may cause the same trouble mentioned above about a daemon. But if you can tolerate a little latency, the solution to your problem may be very simple: 1 - Make your Django app write the data that needs to be sent into to a database table 2 - Every minute (or hour, ...) run a cron job (a simple Python script) that checks the database table, establish the needed TCP connection, send it all and cleanup the sent entries from the table. Hope that helps, -- Olivier / Samalyse -- Olivier Guilyardi / Samalyse --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Application template inheritance and customization
Hi everyone,
I'm working on a Django application, Telemeta, which is currently deployed in 4
projects. Each of these projects have special requirements in regard to
presentation and data display, so that the application templates need to be
slightly customized.
For this purpose I have used template inheritance as shown below.
In the application:
telemeta/templates/telemeta_default/somepage.html:
{% extends "telemeta/base.html" %}
{% load telemeta_utils %}
{% block content1 %}
[...]
{% endblock %}
{% block content2 %}
[...]
{% endblock %}
telemeta/templates/telemeta/somepage.html:
{% extends "telemeta_default/somepage.html" %}
And in the project:
project/templates/telemeta/somepage.html:
{% extends "telemeta_default/somepage.html" %}
{% block content1 %}
(Customize content1 here...)
{% endblock %}
With this mechanism, when Django tries to resolve telemeta/somepage.html, it
uses the project specific template, and ignore the default one. However, it can
still inherit from the /real/ default template, which is located in
telemeta_default/somepage.html. This way, there is no need to replicate the
whole default template to customize it.
But, do you see a way to avoid those single-line "templates" located in
telemeta/templates/telemeta?
--
Olivier Guilyardi / Samalyse
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Splitting tests.py
Hi, I'm trying to split tests.py into individual files into a tests/ subfolder, but that doesn't work. I correctly import everything from within tests/__init__.py, as previously said on this mailing list: http://groups.google.com/group/django-users/browse_frm/thread/10cfd65e398360d2/dae3a7226dccdc5f But that doesn't work. I tested on Django 1.0.2 and SVN r12255, same thing. Any clue? -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Splitting tests.py
On 01/18/2010 09:19 PM, Reinout van Rees wrote: > On 01/18/2010 08:40 PM, Olivier Guilyardi wrote: >> Hi, >> >> I'm trying to split tests.py into individual files into a tests/ >> subfolder, but >> that doesn't work. >> >> I correctly import everything from within tests/__init__.py, as >> previously said >> on this mailing list: >> http://groups.google.com/group/django-users/browse_frm/thread/10cfd65e398360d2/dae3a7226dccdc5f >> >> >> But that doesn't work. I tested on Django 1.0.2 and SVN r12255, same >> thing. > > Wild guess: place the test code in normal python test files inside the > tests/ folder instead of in the __init__.py? (I tend to keep that one > virtually empty anyway). Yes, I like it almost empty too :) > Again: pretty wild guess ;-) My __init__.py just contains an import statement, that is: from individual_test import * where individual_test.py resides in tests/ It doesn't work so far. I'm not sure why, but splitting individual files tend to be a complex matter in my Django experience. For example, when moving models from models.py to models/, I needed to add an app_label to models' Meta class. That's a different problem, but there seem to be some obscurity in the way things get loaded. -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Splitting tests.py
On 01/18/2010 08:59 PM, Shawn Milochik wrote: > Here's a fantastic resource. It's what I used to switch to this methodology. > It talks you through exactly how to do this. > > http://ericholscher.com/blog/2008/nov/4/introduction-pythondjango-testing-basic-unit-tests/ Oh yes, I found this one. The following doesn't work in my case (quoted from the page you cite): "Unit tests are a lot easier to import than doctests. You simply do a from import . I named my unit test file unittst.py, and python will import that from the current directory. You are importing the test classes that you defined in your file. So I could have as easily put from unittest import TestBasic and it would work. Using the import * syntax allows us to add more tests to the file later and not have to edit it. " -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Splitting tests.py
On 01/18/2010 09:58 PM, Shawn Milochik wrote: > On Jan 18, 2010, at 3:50 PM, Olivier Guilyardi wrote: > >> On 01/18/2010 08:59 PM, Shawn Milochik wrote: >>> Here's a fantastic resource. It's what I used to switch to this >>> methodology. It talks you through exactly how to do this. >>> >>> http://ericholscher.com/blog/2008/nov/4/introduction-pythondjango-testing-basic-unit-tests/ >> Oh yes, I found this one. >> >> The following doesn't work in my case (quoted from the page you cite): >> >> "Unit tests are a lot easier to import than doctests. You simply do a from >> import . I named my unit test file unittst.py, and >> python >> will import that from the current directory. You are importing the test >> classes >> that you defined in your file. So I could have as easily put from unittest >> import TestBasic and it would work. Using the import * syntax allows us to >> add >> more tests to the file later and not have to edit it. " >> > > Then what does your tests/__init__.py look like? > > Mine looks like this: > > from address_tests import * > from random_tests import * > from other_tests import * > > #where the tests folder contains address_tests.py, random_tests.py, and > other_tests.py. $ cat tests/__init__.py from model_tests import * $ find tests tests tests/model_tests.py tests/__init__.py Django doesn't see my test cases unless I move tests/model_tests.py to tests.py. One thing though: the tests directory (or tests.py if I revert it) is not at the root of a project, it's located in an application that I'm developing. -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Splitting tests.py
On 01/18/2010 10:04 PM, Ramiro Morales wrote: > On Mon, Jan 18, 2010 at 4:40 PM, Olivier Guilyardi wrote: >> Hi, >> >> I'm trying to split tests.py into individual files into a tests/ subfolder, >> but >> that doesn't work. >> >> I correctly import everything from within tests/__init__.py, as previously >> said >> on this mailing list: >> http://groups.google.com/group/django-users/browse_frm/thread/10cfd65e398360d2/dae3a7226dccdc5f >> >> But that doesn't work. I tested on Django 1.0.2 and SVN r12255, same thing. >> >> Any clue? > > What do you mean with "doesn't work" ?. Do you get a traceback? No > error but your > tests aren't being run?, ... No error, the tests are not run. When splitting, it says: Ran 0 tests in 0.000s Instead of the following with tests.py: Ran 14 tests in 1.875s > Try with SVN r12254 because the test infrastructure was refactored in r12255 > and it still has some small rough edges. I reverted back to r12254, same problem. -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Splitting tests.py
On 01/18/2010 10:21 PM, Olivier Guilyardi wrote:
> On 01/18/2010 10:04 PM, Ramiro Morales wrote:
>> On Mon, Jan 18, 2010 at 4:40 PM, Olivier Guilyardi wrote:
>>> Hi,
>>>
>>> I'm trying to split tests.py into individual files into a tests/ subfolder,
>>> but
>>> that doesn't work.
>>>
>>> I correctly import everything from within tests/__init__.py, as previously
>>> said
>>> on this mailing list:
>>> http://groups.google.com/group/django-users/browse_frm/thread/10cfd65e398360d2/dae3a7226dccdc5f
>>>
>>> But that doesn't work. I tested on Django 1.0.2 and SVN r12255, same thing.
>>>
>>> Any clue?
>> What do you mean with "doesn't work" ?. Do you get a traceback? No
>> error but your
>> tests aren't being run?, ...
>
> No error, the tests are not run. When splitting, it says:
>
> Ran 0 tests in 0.000s
>
> Instead of the following with tests.py:
>
> Ran 14 tests in 1.875s
>
>> Try with SVN r12254 because the test infrastructure was refactored in r12255
>> and it still has some small rough edges.
>
> I reverted back to r12254, same problem.
Okay, I found the problem. In my tests I'm importing models, with something
like:
from models import ...
That works when tests.py is located at the root of the app, that is: at the same
level as the models module.
But when splitting tests.py into individual files into tests/, models can't be
imported anymore. For it to work, I must use :
from my_app.models import ...
And now it works. The real problem here is that Django current behaviour is
silent failure, no error.
A little debugging led me in django.test.simple.get_tests() (at r12555 line 65):
try:
app_path = app_module.__name__.split('.')[:-1]
test_module = __import__('.'.join(app_path + [TEST_MODULE]), {}, {},
TEST_MODULE)
except ImportError, e:
# Couldn't import tests.py. Was it due to a missing file, or
# due to an import error in a tests.py that actually exists?
import os.path
from imp import find_module
try:
mod = find_module(TEST_MODULE,
[os.path.dirname(app_module.__file__)])
except ImportError:
# 'tests' module doesn't exist. Move on.
test_module = None
Here the __import__ fails, not because the tests module is missing, but because
the tests module fails to import another module.
And then, the find_module() fallback fails too: my debugging shows that
os.path.dirname(app_module.__file__) points to /path/to/myapp/models and *not*
to /path/to/myapp as it should be.
This could be caused by the fact that my models are also split into models/,
thus dirname() returns a bogus value. But app_path above is correct, since it
doesn't rely on the fact the models module is a file...
Hum.. My head hurts ;)
--
Olivier
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Splitting tests.py
On 01/20/2010 10:58 AM, Matt Schinckel wrote: > On Jan 19, 7:21 am, Olivier Guilyardi wrote: >> On 01/18/2010 10:04 PM, Ramiro Morales wrote: >> >> >>> On Mon, Jan 18, 2010 at 4:40 PM, Olivier Guilyardi wrote: >>>> Hi, >>>> I'm trying to split tests.py into individual files into a tests/ >>>> subfolder, but >>>> that doesn't work. [...] >> No error, the tests are not run. When splitting, it says: >> >> Ran 0 tests in 0.000s >> >> Instead of the following with tests.py: >> >> Ran 14 tests in 1.875s >> [...] > Drop into ./manage.py shell, and make sure you can import app.tests: > errors doing this will silently fail. > > (May or may not solve your problem, but it has happened to me about a > dozen times today: I split my tests.py into: > > tests/ > __init__.py > integration/ > __init__.py > *.py > unit/ > __init__.py > *.py > > and so on.) Please see my last mail, this issue is resolved. Indeed it was import-related and silently failing. I believe this is a Django bug, although I got no comments to my last post. -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Splitting tests.py
On 01/20/2010 01:21 PM, Matt Schinckel wrote: > On Jan 20, 9:25 pm, Olivier Guilyardi wrote: [...] >> Please see my last mail, this issue is resolved. Indeed it was import-related >> and silently failing. > > Yes, it came through as I was replying :) Then I think that it would be better to follow up on this other post of mine (01/18/2010 11:04 PM). >> I believe this is a Django bug, although I got no comments to my last post. > > It is certainly annoying: tests just don't run, and the only way to > find out why is to drop into a shell and import the offending > module... Indeed, silent failures are truly frustrating. Noisy errors are a blessing in comparison. > Might put some time into finding out why exceptions are not propagated > while importing tests in django. I already spent some time debugging this, and explain what happens (and might happen) in my previous post. -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Iterating over a QuerySet
For best performances, should I: records = MyModel.objects.all() for item in records: ... or is the following ok: for item in MyModel.objects.all(): ... ? -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Iterating over a QuerySet
On 01/20/2010 08:41 PM, Daniel Roseman wrote: > On Jan 20, 7:09 pm, Olivier Guilyardi wrote: >> For best performances, should I: >> >> records = MyModel.objects.all() >> for item in records: >> ... >> >> or is the following ok: >> >> for item in MyModel.objects.all(): >> ... >> >> ? > > There is no difference, except for the infinitesimal amount of time > for the extra variable lookup. The only difference is readability, or > if you need to use the same queryset again. Thanks! -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Dealing with polyhierarchical data
Hi, I'm working with a polyhierarchical thesaurus, and trying to handle that in Django. By polyhierarchical, I mean : nodes can have both multiple parents and children. Actually, this is a geographical thesaurus, and yes a location can have multiple parents (being across countries, etc..). I have read about the Nested set paradigm [1], and would love to use that, maybe through django-mptt or django-treebeard. But unless someone shows me how, nested sets aren't suitable for polyhierarchical data. Currently I have a simple recursive many-to-many mapping. This allows to establish the poly-relations, but is completely unusable for real use cases. For instance, I have a table of "items", with a "location" field which points to a location in the thesaurus. Now I need to list all items which are located in a given country. I just can't filter by country, there's no such field in the items table. And a location can be of any level of precision, such as country, region, city, village, etc.. The nested set would be perfect for this, but apparently can't handle multiple parents. Do you see a fast and elegant way to handle this ? [1] http://dev.mysql.com/tech-resources/articles/hierarchical-data.html -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Dealing with polyhierarchical data
On 01/28/2010 11:12 AM, Matthias Kestenholz wrote: > Hi > > On Wed, Jan 27, 2010 at 11:29 PM, Olivier Guilyardi wrote: >> Hi, >> >> I'm working with a polyhierarchical thesaurus, and trying to handle that in >> Django. By polyhierarchical, I mean : nodes can have both multiple parents >> and >> children. >> >> Actually, this is a geographical thesaurus, and yes a location can have >> multiple >> parents (being across countries, etc..). >> >> I have read about the Nested set paradigm [1], and would love to use that, >> maybe >> through django-mptt or django-treebeard. But unless someone shows me how, >> nested >> sets aren't suitable for polyhierarchical data. >> >> Currently I have a simple recursive many-to-many mapping. This allows to >> establish the poly-relations, but is completely unusable for real use cases. >> >> For instance, I have a table of "items", with a "location" field which >> points to >> a location in the thesaurus. >> >> Now I need to list all items which are located in a given country. >> >> I just can't filter by country, there's no such field in the items table. >> And a >> location can be of any level of precision, such as country, region, city, >> village, etc.. >> >> The nested set would be perfect for this, but apparently can't handle >> multiple >> parents. >> >> Do you see a fast and elegant way to handle this ? >> >> [1] http://dev.mysql.com/tech-resources/articles/hierarchical-data.html >> > > Maybe you could take a look at this project? > http://bitbucket.org/cmutel/django-directed-acyclic-graph/ It's quite interesting indeed. However, it uses database stored functions and triggers, which isn't very portable. What's great about the Nested set solution is that it can be achieved through standard Django model api calls. Unfortunately it doesn't fit the job. I'm still looking for an elegant solution, that I'll hopefully find soon... Thanks -- Olivier -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Dynamic Model Fields
Hi, I'm in the process of turning telemeta [1] into a django application, and need dynamic model fields: we want to allow site administrators to easily add/remove "fields" to our main data structure, the MediaItem, which represents an audio/video resource. Example: for a given research laboratory the MediaItem may need to have a "musicians" field, but for another laboratory it can be "filmmaker", etc... And there may be dozens of these dynamic fields, which could be added/removed at any time. We believe the process of hard-coding those fields into the models is a developer task and too heavy for the administrators we target, especially because of the need to manually modify the SQL tables. Any ideas? Regards, [1] http://svn.parisson.org/telemeta -- Olivier - http://www.samalyse.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Dynamic Model Fields
Tim Chase wrote:
>> I'm in the process of turning telemeta [1] into a django
>> application, and need dynamic model fields: we want to allow
>> site administrators to easily add/remove "fields" to our main
>> data structure, the MediaItem, which represents an audio/video
>> resource.
>
> Our current app does something like this...our basic solution was
> something like one of the two following ideas (depending on
> whether particular categories should be consistent across labs,
> such as "media" meaning the same thing in Lab1 and Lab2)
Actually the labs where just an example: one laboratory will have one
installation of the application, and the dynamic fields will only apply within
the scope of this installation. There's no such thing as consistency accross
labs.
> or the more simple "every lab has its own bag of categories that
> don't relate to anybody else" (this is how we settled on it
> because our clients rarely have much in common for these
> category/value pairs):
>
>
>class Lab(Model):
> pass
>class Category(Model):
> lab = ForeignKey(Lab)
> name = CharField(maxlength=40)
>class Value(Model):
> category = ForeignKey(Category)
> value = CharField(maxlength=40)
>class MediaItem(Model):
> lab = ForeignKey(Lab)
> values = ManyToMany(Values)
Well, that's what I almost did... with support for enumerations (some fields
must only accept predetermined values):
class MediaItem(models.Model):
"Describe an audio/video item with metadata"
title = models.CharField(maxlength=250)
author = models.CharField(maxlength=250)
def get_dynamic_properties(self):
"Retrieve dynamic properties associated with a given media item"
[...]
class MediaItemPropertyDefinition(models.Model):
"Define a media item dynamic property"
TYPE_CHOICES = (('text', 'Text'), ('enumeration', 'Enumeration'))
name = models.CharField(maxlength=64)
type = models.CharField(maxlength=64, choices = TYPE_CHOICES)
class MediaItemPropertyEnumerationItem(models.Model):
"Define a possible value for media item dynamic enumeration properties"
definition = models.ForeignKey(MediaItemPropertyDefinition, core=True)
name = models.CharField(maxlength=250)
class MediaItemProperty(models.Model):
"Associate a value to a media item dynamic property"
definition = models.ForeignKey(MediaItemPropertyDefinition, core=True)
media_item = models.ForeignKey(MediaItem)
value = models.CharField(maxlength=250)
enum_item = models.ForeignKey(MediaItemPropertyEnumerationItem, null=True)
However, watching the MySQL verbose log, I realized that retrieving properties
as well as their definitions (and enumeration values) to properly display an
detail view or edition form execute a _lot_ of SQL queries, when this could be
achieved with one or two joins... I'm afraid it won't scale.
Or does your "ManyToMany(Values)" field helps for optimization?
May I expect any help from manipulators, managers, query sets (all of these are
still a bit obscure to me) ?
Regards,
--
Olivier - http://www.samalyse.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Dynamic Model Fields
Tim Chase wrote: >> Actually the labs where just an example: one laboratory will >> have one installation of the application, and the dynamic >> fields will only apply within the scope of this installation. >> There's no such thing as consistency accross labs. > > It still sounds like the above scheme would do the trick...one > code-base could work for any of the installations. Well, not really. Think of an installation as a "site" in Django, I'm currently working on the "application". Administrators are expected to add/remove dynamic fields within the scope of a given site. In other words, it's some sort of site-specific configuration. >> Or does your "ManyToMany(Values)" field helps for >> optimization? May I expect any help from manipulators, >> managers, query sets (all of these are still a bit obscure to >> me) ? > > ManyToMany neither helps nor hinders performance...it states a > fact about your model. For performance, you may want to try > using the Model.objects.select_related() call. This pulls in the > items related to your search, so you can do things like > >MediaItem.objects.filter(author='Smith').select_related() > > This should help reduce the number of hits on the DB by telling > Django to pull them all back in one pass. Thank you (and to Gulopine) for pointing this out. > This scheme does have one small complicating factor wherein if > you want MediaItems with property1='foo' and property2='bar', you > have to jump through some hoops. Some dark-art SQL-foo can solve > the problem, but it's not a pretty scene. As long as you only > limit it one property, Django's good: > >items = MediaItem.objects.select_related().filter( > property__category__name='MyProp' > ).filter(property__value='MyValue') Okay > (adjusting for your model). Asking for multiple properties is > akin to asking > >SELECT * FROM tblFoo WHERE x=1 AND x=2 > > and returns no rows (because there's no way to have x be both > values...unless you have I see >> SELECT Owner FROM tblCat WHERE state='alive' AND state='dead' > >Owner > >Schroedinger > > ...a little feeble SQL/metaphysics humor there) Apparently we're not going to deal with cats ;) > However, if you know which piece of your cross-cutting will have > the smaller results, you can do things like the above and then > filter the resulting items based on whether they have properties > 2..N such as > >new_items = [] >for item in items: > for property in item.property: >if (property.value=='MyValue2' and >property.category.name=='MyName2'): > new_items.append(item) > > It's not ideal for high volumes of data or high volumes of > traffic, but should be sufficient for most small uses. Okay, I got the point. Now, there's another problem with the above method: it doesn't play nice with Django's auto-admin interface and generic views. Additionally, that makes 4 models for what is conceptually one thing : a media item. What about a radically different idea: a command line tool that would "modify" the models and SQL tables in one go. Say something like: $ telemeta-admin addfield musicians charfield This would retain all of the power/simplicity of Django admin interface. I'm not sure how this could be generalized to get included into Django's manage.py, but a such command line tool would be rather feasible within the scope of telemeta. However, I don't like the idea of modifying the python models code with this tool. I'd prefer the models to be customized by loading some external fields definitions, say from an XML file. I'm still a python newbie, but it seems to me that there could be a way to modify the model definition before Django knows about it: === start of models.py === class MediaItem(models.Model): "Describe an audio/video item with metadata" title = models.CharField(maxlength=250) author = models.CharField(maxlength=250) # Parse some external XML file defining the dynamic fields and then add them # to the class definition with something similar to: MediaItem.foobar = models.CharField(maxlength=250) === end of models.py === I tried it: when I load the model withing the python shell, the class does have a foobar attribute. However, when I run python manage.py sql, the foobar field is gone... Any idea? -- Olivier - http://www.samalyse.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Dynamic Model Fields
Olivier Guilyardi wrote: > I'm still a python newbie, but it seems to me that there could be a way to > modify the model definition before Django knows about it: Okay, I found the Field.contribute_to_class() method which seems to work just fine. I'm calling it right after my model class declaration, in models.py: test_field = models.CharField(maxlength=250) test_field.contribute_to_class(MediaItem, 'test_field') This should allow me to load dynamical fields definitions from an external configuration file. But is it ok to use contribute_to_class() directly? May this break with future Django releases? Regards -- Olivier - http://www.samalyse.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Named URL problem
Hi,
Named URLs don't work for me so far. I'm using rev 5180.
In my site's urls.py I have:
(r'^', include('telemeta.urls')),
In telemeta/urls.py:
url(r'^collections/(?P[0-9A-Z._-]+)/?$',
'django.views.generic.list_detail.object_detail',
dict(all_collections, template_name="collection_detail.html"),
name="telemeta-collection-detail"),
The following raise no error and renders nothing:
{% url telemeta-collection-detail p.id %}
Same thing with:
{% url telemeta-collection-detail object_id=p.id %}
What am I doing wrong ?
--
Olivier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Named URL problem
[EMAIL PROTECTED] wrote:
> I'd suggest trying {% url telemeta-collection-detail object.id %}
Thanks that fixed it ! It's not object.id, it's p.id, but it wasn't defined at
this point in the template. It put the statement back in the loop where p.id is
defined and it works great :)
--
Olivier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Custom filter/tag and template inheritance
Hi,
I have a custom filter which I expect to use in many templates. So instead of
adding {% load my_lib.py %} into every template I'd like to put it into
base.html which all templates extend.
But it doesn't work: when I move the load statement to the parent template and
access the child template I get a TemplateSyntaxError "Invalid filter".
Is this the expected behaviour?
--
Olivier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Limiting SQL queries in a custom manager method
Hi,
How can I know about the limiting parameters inside a custom manager method?
Example:
class MyManager(models.Manager):
def my_query(self):
# How can I find out about offset and length ?
cursor.execute("SELECT foo FROM bar LIMIT %d, %d", [offset, length])
class MyModel(models.Model)
foo = models.CharField(maxlength=200)
my_objects = MyManager()
# The following should result in offset=0 and length=5 above
first_rows = MyModel.my_objects.my_query()[:5]
Is this possible?
Regards,
--
Olivier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Limiting SQL queries in a custom manager method
Malcolm Tredinnick wrote:
> On Fri, 2007-05-18 at 23:50 +0200, Olivier Guilyardi wrote:
>>
>> How can I know about the limiting parameters inside a custom manager method?
>>
>> Example:
>>
>> class MyManager(models.Manager):
>> def my_query(self):
>> # How can I find out about offset and length ?
>> cursor.execute("SELECT foo FROM bar LIMIT %d, %d", [offset, length])
>>
>> class MyModel(models.Model)
>> foo = models.CharField(maxlength=200)
>> my_objects = MyManager()
>>
>> # The following should result in offset=0 and length=5 above
>> first_rows = MyModel.my_objects.my_query()[:5]
>>
>> Is this possible?
>
> Not really, no. Python will process the slice arguments ("[:5]") after
> it has called my_query().
Okay, so I suppose a workaround is to pass offset and length as arguments to
my_query()
> The way we work around this in QuerySet is to ensure that every QuerySet
> method (with a few exceptions) returns another QuerySet and we implement
> __getslice__ on the QuerySet class. You would need to emulate that
> behaviour if you really wanted this.
I see. I would need to return an object that implements __getslice__, and
perform my SQL query in this object.
I suppose I may also try to extend the QuerySet class to add my own method. But
this might get rather complex AFAICS in db.models.query.
Thanks for the tips
--
Olivier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Limiting SQL queries in a custom manager method
Jeremy Dunck wrote: > On 5/18/07, Olivier Guilyardi <[EMAIL PROTECTED]> wrote: > ... >> Okay, so I suppose a workaround is to pass offset and length as arguments to >> my_query() >> > ... >> I suppose I may also try to extend the QuerySet class to add my own method. >> But >> this might get rather complex AFAICS in db.models.query. > > If you give a better idea of what you're trying to accomplish, there > may be an easier way. > > Have a look at db.query.Q, for example, which can be used to build > queries in a flexible way, for example: > http://www.djangoproject.com/documentation/db-api/#complex-lookups-with-q-objects I'm already using Q for other purposes, but I'm afraid it won't help here. Here's what I want to run custom SQL for: I have collections and items, many items relate to one collection. Each item comes from a given country. In the item table there's a country field, but there is no such field in the collection table. One collection may contain items that come from several countries. I want to display all collections that contain items which come from a given country, say Guatemala. There's much data, so I need to paginate through those displayed collections after they've been ordered by title. In SQL I would do: SELECT DISTINCT collection.* FROM collection INNER JOIN item ON collection.id = item.collection_id WHERE item.country = 'Guatemala' ORDER BY collection.title LIMIT 0, 20; -- Olivier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Reverse URL resolver fails with a literal dot
Hi,
In my urls.py I have the following entry:
url(r'^items/download/(?P[0-9A-Za-z._:%?-]+)\.(?P[0-9a-z]+)$',
web_view.item_export,
name="telemeta-item-export"),
In my template:
{% url telemeta-item-export item.id|urlencode,format.extension %}
For item.id = "BM.001:006" and format = "mp3", it produces
/items/download/BM.001%3A006%5C.mp3
Which, once url-decoded, is equivalent to (notice the backslash):
/items/download/BM.001:006\.mp3
If I access this url I get a "Page not found" with Django complaining about the
fact it did not match any of the url patterns.
However, if I manually remove the backslash and access
/items/download/BM.001%3A006.mp3, then it works.
This seems to mean that the resolver and the reverse resolver are not
symmetrical. Is this a bug?
Regards,
--
Olivier
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Reverse URL resolver fails with a literal dot
akonsu wrote: > i would say that yes it is a bug. i have seen many bugs in the reverse > resolver code. for example, it crashes (throws a python exception) if > a regex pattern contains question marks (optional elements) and i am > sure it has a lot more. my personal opinoin is that this code is > simply a hack. :) I didn't read the code, but this reverse regex feature seems like a really interesting and innovative feature to me (never seen a such thing before). It sounds complex too, though. Maybe that "prototype" is better than "hack" ;) Regards, -- Olivier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Reverse URL resolver fails with a literal dot
Malcolm Tredinnick wrote: >> This seems to mean that the resolver and the reverse resolver are not >> symmetrical. Is this a bug? > > It is. There's a sort of correct patch to fix a few things like this in > Trac, so we'll get to checking it in at some point. Should I post a ticket? Regards, -- Olivier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Reverse URL resolver fails with a literal dot
Malcolm Tredinnick wrote: > On Fri, 2007-05-25 at 11:07 +0200, Olivier Guilyardi wrote: >> Malcolm Tredinnick wrote: >> >>>> This seems to mean that the resolver and the reverse resolver are not >>>> symmetrical. Is this a bug? >>> It is. There's a sort of correct patch to fix a few things like this in >>> Trac, so we'll get to checking it in at some point. >> Should I post a ticket? > > No, because there's already a patch in Trac that's close (#2977). Indeed, I tested this patch, it fixes my problem. Thanks -- Olivier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: Reverse URL resolver fails with a literal dot
akonsu wrote: > yes, it is an innovative feature. i think it is difficult to implement > right. the general problem in my understanding is to be able to > generate a regex that accepts a (partial) input string. then, to > compare the generated regex with the list in the urls module. this > involves programming language theory that deals with finite automata. > from the bugs that I see in this code it seems that it does not rely > on this theory but rather attempts to manipulate regular expressions > as strings. The patch on #2977 contains a rewrite of the reverse resolver. Ain't sure it relies on "finite automata", but you might want to to check it out. It works great for me. Regards -- Olivier --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
