Where to put initializing code
Hi Django users,
I have a project made of several app and I am adding a 'search' app
which provides searching facilities across all apps. Each app whose
content can be searched needs to register with the search app with
code such as:
def search_genf(request, search_terms):
# generate weighed results
from project.search import register
register('Category name', search_genf)
My question is: how should I make an app register?
At the moment, I am putting the registering code in app/__init__.py,
which is automatically run when the server starts, but I don't know if
this is a good idea. My other idea was to add a 'search.py' file to
each searchable app, and have code such as this is search/
__init__.py :
for app in settings.INSTALLED_APP:
# if app has file search.py, import it and register its search
function(s)
However, I feel like I am not doing it right.
What, in your opinion, would be a good way to go about doing this?
--
Arnaud
--~--~-~--~~~---~--~~
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: Where to put initializing code
On Oct 5, 7:12 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> Arnaud Delobelle wrote:
> > Hi Django users,
>
> > I have a project made of several app and I am adding a 'search' app
> > which provides searching facilities across all apps. Each app whose
> > content can be searched needs to register with the search app with
> > code such as:
>
> > def search_genf(request, search_terms):
> > # generate weighed results
>
> > from project.search import register
> > register('Category name', search_genf)
>
> > My question is: how should I make an app register?
[...]
> > What, in your opinion, would be a good way to go about doing this?
>
> You might want to look at the code for admin.autodiscover(), which scans
> the various apps for an admin model. You could do something similar for
> your search functionality. It's doing pretty much what you already do,
> though.
I'll have a look there, thanks.
--
Arnaud
--~--~-~--~~~---~--~~
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: Redirect user to dynamic url after login
On Oct 11, 2:55 pm, "F.Pighi" <[EMAIL PROTECTED]> wrote: > Hi all, I'm a newbie and I'm having some trouble with the login > process. > > I just want to redirect the user to /users/(?P[^/]+)/profile > or just /users/(?P[^/]+) after a successful login. > > How can I do it? I tried using the default login view it seems I have > to use the LOGIN_REDIRECT_URL variable in the settings.py, but I don't > know how to specify a dynamic url. > > Should I write my own custom login view or is there a way to > accomplish this even with the default one? > > What am I missing here? > > Thank you very much You can redirect to something like /logged_in, this view has access to request.user so can redirect you to /users/username/ -- Arnaud --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
python manage.py runserver giving strange error
Hello django users, Today I have had this strange error: after a syntax error in a module I had to restart my development server. marigold:qmm arno$ python manage.py runserver /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ Python.app/Contents/MacOS/Python: can't open file 'manage.py': [Errno 2] No such file or directory All of a sudden, Python pretends not to be able to see manage.py! But manage.py is present and what's more: marigold:qmm arno$ python manage.py Type 'manage.py help' for usage. marigold:qmm arno$ python manage.py help runserver Usage: manage.py runserver [options] [optional port number, or ipaddr:port] Starts a lightweight Web server for development. [...] What's going on? I have no idea where to start looking, I am not even sure it's django related (although I have not found any other problem with python). A reboot of the system (Mac OS X 10.5.6) doesn't solve the problem. I would appreciate any hint. -- Arnaud Delobelle. --~--~-~--~~~---~--~~ 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: python manage.py runserver giving strange error
I've avoided the problem by using django-admin instead of manage.py... Which does not tell me what's gone wrong. -- Arnaud --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to include template with current tag definitions
Hi all,
I would like to be able to include a template from another template so
that the included template understands the tag definitions defined in
the including template, but I can't think of a simple way to do it.
E.g. say that mytags defines a tag called "mytag". I would like the
following to work
outer.tmpl
{% load mytags %}
{% include "inner.tmpl" %}
/outer.tmpl
inner.tmpl
Here is what my tag does: {% mytag %}
/inner.tmpl
Obviously, it doesn't work because {% include ... %} doesn't pass on
the currently defined tags to the included template. But is there a
simple way to achieve this?
Thanks,
--
Arnaud
--~--~-~--~~~---~--~~
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: newforms select field
On Feb 17, 7:05 pm, "paulh" <[EMAIL PROTECTED]> wrote:
> I feel the following should work:
> class Myform(forms.Form):
> ...publ = forms.ChoiceField(label='Publisher', required=False)
>
> and then in handler I should be able to set the choices dynamically
> by:
>
> def meth(request):
> ...frm=Myform(initial={'publ':((1,2),(2,3),(3,4)))}) #even if the
> brackets are wrong here, they were right in the original
>
That shouldn't work as initial is meant to set the value of a field.
I had the same problem and a peek at the source told me that a
ChoiceField has a 'choices' attribute which is settable so:
form = MyForm(...)
form.fields['publ'].choices = ((1,2),(2,3),(3,4))
will work, but I don't know whether it is the right thing to do (TM).
--
Arnaud
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
python manage.py broken
Hi all
Today I have moved a project that I have been working on to
subversion.
Prior to doing this I made a copy of the source tree and remove all
the *.pyc and the "dot something" files. I then imported the whole
tree to a subversion repository and checked it out again. I worked on
it all day, and committed a few changes but tonight I realised that
python manage.py wasn't working anymore at all (even though the site
works fine through apache+mod_python) ! I include below the error
message when I try the shell.
daffodil:~/django/qmm arno$ python manage.py shell
Traceback (most recent call last):
File "manage.py", line 11, in ?
execute_manager(settings)
File "/opt/local/lib/python2.4/site-packages/django/core/
management.py", line 1447, in execute_manager
execute_from_command_line(action_mapping, argv)
File "/opt/local/lib/python2.4/site-packages/django/core/
management.py", line 1348, in execute_from_command_line
translation.activate('en-us')
File "/opt/local/lib/python2.4/site-packages/django/utils/
translation/trans_real.py", line 195, in activate
_active[currentThread()] = translation(language)
File "/opt/local/lib/python2.4/site-packages/django/utils/
translation/trans_real.py", line 184, in translation
default_translation = _fetch(settings.LANGUAGE_CODE)
File "/opt/local/lib/python2.4/site-packages/django/utils/
translation/trans_real.py", line 167, in _fetch
app = getattr(__import__(appname[:p], {}, {}, [appname[p+1:]]),
appname[p+1:])
AttributeError: 'module' object has no attribute 'test'
And here is the information about my django installation
daffodil:~/django/django_src arno$ svn info
Path: .
URL: http://code.djangoproject.com/svn/django/trunk
Repository Root: http://code.djangoproject.com/svn
Repository UUID: bcc190cf-cafb-0310-a4f2-bffc1f526a37
Revision: 4463
Node Kind: directory
Schedule: normal
Last Changed Author: russellm
Last Changed Rev: 4463
Last Changed Date: 2007-02-07 22:56:53 + (Wed, 07 Feb 2007)
Properties Last Updated: 2006-11-06 18:18:59 + (Mon, 06 Nov 2006)
I have the same problem on my OSX laptop and debian Etch server so I
think it is something that I messed up when I cleaned up the tree
before importing it to my subversion repository but I can't figure out
why.
Any help would be greatly appreciated.
--
Arnaud
--~--~-~--~~~---~--~~
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: conflict between edit_inline and ManyToManyField
arnodel wrote: > Hi everyone, > > I am trying to get to grips with django and so far I find it wonderful! > But I am stuck on the following problem, which I have tried to make a > test case of below (see models.py). The problem is that when I try to > add a new parent with some children, then I get an error relating to > the 'toys' field, namely: > > Child' object has no attribute 'set_toys' > > But if I remove the edit_inline argument from the 'mum' field in the > 'Child' object it works fine. It also works fine if I remove the 'toys' > field from the 'Child' object but keep the edit_inline in the 'mum' > field. > > Can I remedy this by changing something (maybe define my own set_toys > methode, but how?) ? After having had a go at tracing what's going wrong, I have kludged together this solution to my problem by adding the following method to the 'Child' class: class Child(models.Model): [...] def set_toys(self, new_ids): self.toys = [Toy.objects.get(id=new_id) for new_id in new_ids] return True Now everything seems to work fine. Note that the method returns True because where it is needed in the django source it seems to expect a boolean that says whether there was actually a change (I return True because it's the simplest). Is this a bug in django? If so please tell me where to report it. Otherwise I'd be glad to learn how to do things the correct way. > Is there a reason why I shouldn't consider doing things this way? > In short, please enlighten me. > > PS: My version of django advertises itself as "Django version 0.95 > (post-magic-removal)" > > -- models.py --- > from django.db import models > > > class Toy(models.Model): > name = models.CharField(maxlength=20) > > def __str__(self): > return self.name > > class Admin: > pass > > > class Parent(models.Model): > name = models.CharField(maxlength=20) > > def __str__(self): > return self.name > > class Admin: > pass > > > class Child(models.Model): > name = models.CharField(maxlength=20, core=True) > toys = models.ManyToManyField(Toy) > mum = models.ForeignKey(Parent, edit_inline=models.TABULAR) > > def __str__(self): > return self.name > > class Admin: > pass > - end of models.py -- -- Arnaud --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Extension to QuerySet.values()
Hi there,
I quite often find that when using queryset.values() I would like to be
able to define myself the values of the keys, especially when they span
models:
e.g.
my_query_set.values('foo__bar__baz', 'quux',
'another__long__field__name')
Then I end up with dictionaries with unnecessarily long keys. What I'd
like to be able to do is something like:
my_query_set.values('quux', baz='foo__bar__baz',
name='another__long__field__name')
Executing this would yield dictionaries of the type:
{'quux': 2, 'baz': 'type 2', 'name': 'Frobulon'}
I've had a quick look at the ValuesQuerySet class and there seems to be a
simple enough way to get this feature. I'm presenting it in the form of a
new ValuesQuerySet subclass and a monkey patch to the parent QuerySet.
It's not unlikely that it will break some things as this is my first peek
into the QuerySet class. I'd like to know if this is something that other
people feel the need for and if it is worth pushing for inclusion of such a
feature into django.
Cheers,
Arnaud
from django.db.models.query import QuerySet, ValuesQuerySet
class ValuesDictQuerySet(ValuesQuerySet):
def iterator(self):
# Purge any extra columns that haven't been explicitly asked for
extra_names = list(self.query.extra_select)
field_map = self.field_map
field_names = [field_map.get(fname, fname) for fname in
self.field_names]
aggregate_names = list(self.query.aggregate_select)
names = extra_names + field_names + aggregate_names
for row in self.query.get_compiler(self.db).results_iter():
yield dict(zip(names, row))
def _clone(self, klass=None, setup=False, **kwargs):
c = super(ValuesDictQuerySet, self)._clone(klass, **kwargs)
c.field_map = self.field_map
return c
def QuerySet_values_dict(self, *field_list, **field_dict):
fields = list(field_list)
fields.extend(field_dict.values())
field_map = dict(zip(field_dict.values(), field_dict.keys()))
return self._clone(klass=ValuesDictQuerySet, setup=True,
_fields=fields, field_map=field_map)
# Now we monkey-patch QuerySet with the new method
QuerySet.values_dict = QuerySet_values_dict
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/d4f8d6f0-3723-44d5-991a-9c6b3c13165d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Extension to QuerySet.values()
Hi Russ,
Thanks for the feedback. I agree that this could possibly be integrated
into the values() method. I just used a new method in order to minimise
interference with our existing code. I'll read the 'contributing' document
then see if I can find a bit of spare time to do this properly!
Cheers,
--
Arnaud
On Thursday, 10 October 2013 00:44:45 UTC+1, Russell Keith-Magee wrote:
>
> Hi Arnaud,
>
> I can see value in the feature you're describing here.
>
> From a design perspective, my question would be whether a whole new method
> is needed, or whether it could be integrated into the existing values()
> method. There will be some complications around the 'flat' key, but its
> worth exploring the possibilities before we introduce a whole new API entry
> point.
>
> If you're interested in taking this to the next level, we'll need tests
> and documentation for the new feature. If you want to discuss finer details
> of the API, the django-developers mailing list is a better forum. Our
> contribution process is also documented; if you want to get involved in
> contributing to the internals of Django, it's worth giving this document a
> read [1].
>
> [1] https://docs.djangoproject.com/en/1.5/internals/contributing/
>
> Yours,
> Russ Magee %-)
>
> On Wed, Oct 9, 2013 at 6:19 PM, Arnaud Delobelle
>
> > wrote:
>
>> Hi there,
>>
>> I quite often find that when using queryset.values() I would like to be
>> able to define myself the values of the keys, especially when they span
>> models:
>>
>> e.g.
>>
>>my_query_set.values('foo__bar__baz', 'quux',
>> 'another__long__field__name')
>>
>> Then I end up with dictionaries with unnecessarily long keys. What I'd
>> like to be able to do is something like:
>>
>> my_query_set.values('quux', baz='foo__bar__baz',
>> name='another__long__field__name')
>>
>> Executing this would yield dictionaries of the type:
>>
>> {'quux': 2, 'baz': 'type 2', 'name': 'Frobulon'}
>>
>>
>> I've had a quick look at the ValuesQuerySet class and there seems to be a
>> simple enough way to get this feature. I'm presenting it in the form of a
>> new ValuesQuerySet subclass and a monkey patch to the parent QuerySet.
>> It's not unlikely that it will break some things as this is my first peek
>> into the QuerySet class. I'd like to know if this is something that other
>> people feel the need for and if it is worth pushing for inclusion of such a
>> feature into django.
>>
>> Cheers,
>>
>> Arnaud
>>
>>
>>
>> from django.db.models.query import QuerySet, ValuesQuerySet
>>
>>
>> class ValuesDictQuerySet(ValuesQuerySet):
>>
>> def iterator(self):
>> # Purge any extra columns that haven't been explicitly asked for
>> extra_names = list(self.query.extra_select)
>> field_map = self.field_map
>> field_names = [field_map.get(fname, fname) for fname in
>> self.field_names]
>> aggregate_names = list(self.query.aggregate_select)
>>
>> names = extra_names + field_names + aggregate_names
>>
>> for row in self.query.get_compiler(self.db).results_iter():
>> yield dict(zip(names, row))
>>
>> def _clone(self, klass=None, setup=False, **kwargs):
>> c = super(ValuesDictQuerySet, self)._clone(klass, **kwargs)
>> c.field_map = self.field_map
>> return c
>>
>>
>> def QuerySet_values_dict(self, *field_list, **field_dict):
>> fields = list(field_list)
>> fields.extend(field_dict.values())
>> field_map = dict(zip(field_dict.values(), field_dict.keys()))
>> return self._clone(klass=ValuesDictQuerySet, setup=True,
>> _fields=fields, field_map=field_map)
>>
>>
>> # Now we monkey-patch QuerySet with the new method
>> QuerySet.values_dict = QuerySet_values_dict
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/d4f8d6f0-3723-44d5-991a-9c6b3c13165d%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/24ceded6-9bb8-454b-968e-f3883fe4c14e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Extension to QuerySet.values()
On Thursday, 10 October 2013 15:19:32 UTC+1, Ramiro Morales wrote: > > > On Oct 10, 2013 10:02 AM, "Arnaud Delobelle" > > wrote: > > > > Hi Russ, > > > > Thanks for the feedback. I agree that this could possibly be integrated > into the values() method. I just used a new method in order to minimise > interference with our existing code. I'll read the 'contributing' document > then see if I can find a bit of spare time to do this properly! > > > FYI IIUC this has been reported in ticket 16735: > > https://code.djangoproject.com/ticket/16735 > Yes. The patch also seems to allow using the aliases in e.g. order_by() or annotate() clauses, which I hadn't got round to looking at yet. It is marked as needing improvement but looking at the change history I'm not sure what needs to be improved. -- Arnaud -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a2cbb3b0-e014-46c0-99d5-b71acbeb4aa4%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
