Re: dynamic method calling
Ivan Sagalaev wrote:
> if hasattr(self, 'get_%s_content' % self.name):
> raise Exception('Method does not exists')
Typo: there should be `if not hasattr`, obviously.
--~--~-~--~~~---~--~~
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 method calling
Chris wrote:
> try:
> push = getattr(self, 'get_%s_content' % self.name)
> except AttributeError:
> raise "Method does not exist"
> if callable(push):
> push(**argv)
There are a couple of problems with this code.
1. It's more readable to call hasattr than to catch an exception from
getattr:
if hasattr(self, 'get_%s_content' % self.name):
raise Exception('Method does not exists')
if callable(push):
push(**argv)
2. Raising another exception instead of the standard AttributeError
looks suspicious. Why are you doing it?
3. Exceptions should be instances of class Exception, not strings.
4. The code silently does nothing when attribute is here but is not
callable.
Of all these, points 1 and 3 are certainly worth addressing but for 2
and 4 you may have valid reasons which I don't know :-)
--~--~-~--~~~---~--~~
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: Subtle Memory Leak Finally Found! (DEBUG is off)
7timesTom wrote: > cars = Car.objects.filter(...) #upto 2000 items > msg =... len(cars) # can you see the massive memory use here? This is actually well documented: http://docs.djangoproject.com/en/dev/ref/models/querysets/#when-querysets-are-evaluated --~--~-~--~~~---~--~~ 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: Custom upload handlers: Potential multi threading, session, etc issues. Take a look!
truebosko wrote: > What I found though, is that the view that is being called from JS > will finally have access to the session variable after the upload is > complete Looks like you're doing it with development server. It's single-process and can't handle and upload and another view simultaneously. It should work as you expect in production environment where web servers can handle multiple requests at once. --~--~-~--~~~---~--~~ 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: DJANGO 1.0 : How to avoid converting to entities
Malcolm Tredinnick wrote: >> Better yet, the thing that creates colorizedCode should mark it as >> "safe" (i.e. not requiring escaping) in this fashion: >> >> from django.utils.safestring import mark_safe >> def colorize(): >> # ... >> return mark_safe(result) > > Although if you ever write anything like that you are also responsible > for escaping the existing code. Good point, thanks. I've took a liberty to suppose that if it's about "colorizing" then it's probably some tool that generates HTML from a language source and probably is indeed safe. --~--~-~--~~~---~--~~ 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: DJANGO 1.0 : How to avoid converting to entities
tsmets wrote:
> OK !
> I found it : http://code.djangoproject.com/wiki/AutoEscaping
>
> {% autoescape off %}
> {{ body }}
> {% endautoescape %}
Or just {{ body|safe }}.
Better yet, the thing that creates colorizedCode should mark it as
"safe" (i.e. not requiring escaping) in this fashion:
from django.utils.safestring import mark_safe
def colorize():
# ...
return mark_safe(result)
--~--~-~--~~~---~--~~
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: ANNOUNCE: Django 1.0 released
dankelley wrote: > In other words, should I (or typical users) download the official 1.0 > version, or will it still be advised to track the development version? Nothing can stop you from using trunk :-) I'm not a core developer so don't take it as an official advice. But I do think that living on the edge in the case of Django is most rewarding. --~--~-~--~~~---~--~~ 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: Slovkian speakers? Help wanted with #8709
Frantisek Malina wrote: > Sadly, I am not aware of any current Slovak Django users. > E.g. First 50 results on http://google.sk/search?hl=sk&lr=lang_sk&q=django > won't return a single blog-post about Django web framework in Slovak. May be contact one of those: http://djangopeople.net/sk/ ? Gábor Farkas, for one, is a well-known Django person. --~--~-~--~~~---~--~~ 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: Generic Views and ModelAdmin: too much code?
fabio natali wrote:
> For the sake of clarity, my django project is named arteak, the models
> we are using belong to an app called "management".
Ah! Then there should of course be get_model('management',
kwargs.pop('model')). I thought 'arteak' was the name of the app. This
is why it returns None instead of a model right now.
--~--~-~--~~~---~--~~
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: Generic Views and ModelAdmin: too much code?
fabio natali wrote:
> That's right! So here comes my current urls.py:
>
> http://dpaste.com/72638/
>
> then the traceback I get at http://localhost:8000/:
>
> http://dpaste.com/72639/
Oy! I've found it :-). It has nothing to do with model_view decorator or
anything that we're talking here about. It's in urls.py, on line 30:
(r'^$', 'current_datetime')
You pass a string instead of a function. Django tries to import this
name, fails and tries to call it as a function. Then you get this error
because strings are not callable.
> and finally the traceback I get at http://localhost:8000/manufacturer/:
>
> http://dpaste.com/72637/
Ok... I've finally managed to actually check what I has "invented" and
it seems I was on crack... Sorry for the confusion. I've messed up
building model_classes dict in two places but it doesn't matter because
it can be done simpler.
from django.db.models import get_model
def model_view(func):
def wrapper(request, *args, **kwargs):
model = get_model('arteak', kwargs.pop('model'))
kwargs['queryset'] = model.objects.all()
return func(request, *args, **kwargs)
return wrapper
It happens that Django already has a registry of all models and
get_model can, well, get a model from it by an app_name ('arteak') and a
model_name which is passed in kwargs right out of urlconf.
And model_classes code can be just thrown away.
--~--~-~--~~~---~--~~
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: Generic Views and ModelAdmin: too much code?
fabio natali wrote: >> import models > > I added the line > > import arteak.management.models It's not the same thing :-). This line won't load the name "models" into your local environment. If you want import from some path this should be: from arteak.management import models > TypeError at / > 'str' object is not callable Can you provide full traceback? It's pretty hard to guess where this happens. > Anyway I don't want to steal your time any longer. I really hoped > saving some lines in urls.py could be easier. I'd probably better to > write a short bash script to generate a urls.py file from my models.py > with all the proper generic views entries for each model. Well... The choice is yours. However I'd suggest to spend some time getting yourself more familiar with Python because Django is just Python in many ways. --~--~-~--~~~---~--~~ 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: Generic Views and ModelAdmin: too much code?
fabio natali wrote: > This is the urls.py I created: http://dpaste.com/72138/ > It doesn't work though: I get a > KeyError at /manufacturer > u'manufacturer' > when accessing http://localhost:8000/manufacturer > (manufacturer being one of my model) KeyError says that it can't find a key 'manufacturer' in dict model_classes. This leads me to think that model_classes is empty. It can be because my example is creating it by listing you module "models": ... for i in dir(models) ... and I don't see where this "models" is imported. I was a bit sloppy when I was writing it and have it omitted. So you should import it. It's simply import models if it's in the same directory as urls.py. --~--~-~--~~~---~--~~ 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: Multi DB question
shabda wrote:
>> You could use SQLAlchemy to access your forum database, as long as you
>> don't need it in the admin.
>
> As, I just need to access the other DB in one place, I think this is
> the way to go here.
Come on guys! If you just need to create a record in a DB you certainly
don't need *any* framework for it. It's a Python world, you can just
write stuff here, not wait for any vendor to supply a framework for
every possible movement.
This is as simple as:
db = MySQLdb.connect(host='..', user='..', passwd='..')
cursor = db.cursor()
cursor.execute('insert into .. ')
--~--~-~--~~~---~--~~
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: UnicodeDecodeError: markdown failing to parse data fed by django
fizban wrote: > On 12 Apr, 12:54, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: >> It sounds like you're using markdown 1.7. We haven't yet incorporated >> the patch necessary to handle markdown 1.7 along with the earlier >> versions. That will go in soon, though -- there's already a ticket in Trac >> for it. > > Ok, that sounds cool (the pending fix, not the backwards incompatible > changes); thank you for the reply BTW, there is [python-markdown2][1] that doesn't have problems with neither unicode, nor byte strings in utf-8. [1]: http://code.google.com/p/python-markdown2/ --~--~-~--~~~---~--~~ 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: Error Message Best Practice Question
[EMAIL PROTECTED] wrote:
> This seems kind of hacky, but it really seems like it makes sense to
> show this as a form error. The only other way I could think to solve
> this was to pass the request to the model and then check the above in
> the clean method, however this seems just as bad as it breaks the
> separation between the view and the model. Does anyone have a
> different suggestion as to how to do this cleanly?
It's really better to have this check in clean_number method of the form
since it's effectively a field's error. Your form declaration would look
like this:
class CreditCardForm(ModelForm):
class Meta:
model = CreditCard
def __init__(self, user, *args, **kwargs)
super(CreditCardForm, self).__init__(*args, **kwargs)
self.user = user
def clean_number(self):
if CreditCard.objects.filter(
number=self.cleaned_data['number'],
user=self.user):
raise ValidationError('Duplicate Credit Card')
return self.cleaned_data['number']
Note that form's __init__ accepts a user object that is required for
this check. This will separate form logic from web request. In a view
you instantiate the form like this:
form = CreditCardForm(request.user, request.POST)
--~--~-~--~~~---~--~~
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: Django auth user relation to other connected objects
Przemyslaw Wroblewski wrote:
> When I started using django I create sth like this in my views:
>
> Somemodel.objects.filter(user = request.user)
>
> But I don't like that scheme, I just want to create something similar
> to rails like:
>
> "current_user.somemodel.find_by_name('x')"
You want this:
request.user.somemodel_set.filter(name='x')
This will work as soon as you have a foreign key to User in SomeModel.
If you don't like automatically named attribute "somemodel_set" you can
set this name on a foreign key relation:
class SomeModel(models.Model):
user = models.ForeignKey(User, related_name='somemodels')
and then use:
request.user.somemodels.filter(name='x')
--~--~-~--~~~---~--~~
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: Understanding autoescape-aware filters
Thanks for clarification! I have couple more things to iron out though... Malcolm Tredinnick wrote: > If we didn't have is_safe, every filter that did some kind of string > manipulation such as input = intput + 'x' would need to end with lines > like > > if isinstance(orig_input, SafeData): > result = mark_safe(result) > return result > > and they would have to remember to save the original input (or test its > type very early). Got it now. So if I understand correctly - mark_safe means that filter takes full responsibility for its output - .is_safe means that filter doesn't want to know details of its input and thus takes responsibility only for its own additions > Finally, auto-escaping is only appropriate for HTML text. Yes, I've completely forgot about emails etc... :-( This now makes sense why one might want to not escape and mark_safe output. > However, some of your filters might still be > useful in those sorts of sections. Imagine, for example, a filter that > always replaced the word "and" by "&". It will need to behave > differently in different auto-escaping contexts (use "&" in HTML > templates, and "&" in email). And this is a very clear example :-). > I've rewritten most of the filtering and auto-escaping section (in > [6692]). Have a read of it and see if it makes more sense from the point > of view of where you were 24 hours ago. I've tried to approach it from a > different direction, hopefully motivating things a bit more without > getting us bogged down in unimportant details. Yes, it really is better now! Thanks :-). There are a couple of small points however: > This attribute tells Django that is a safe string is passed into your filter, the result will still be safe I kinda think that emphasizing the safeness of input here is distracting. I'd rather emphasize that ".is_safe" means that author doesn't want to think of input very much and wants to let Django think for him, and the details of how it will be done are not important. They are still interesting though and might be noted afterwards. Something like this (though it's a bit verbose): This attribute tells Django that your filter works with various input types and can only be sure that it doesn't do any "unsafe" changes to it. Django will then decide if the whole output needs to be escaped or not keeping track of whether or not input was already safe. Another thing is the example code of initial_letter_filter. I think it can be written shorter and without lambda: -if autoescape: -esc = conditional_escape -else: -esc = lambda x: x -result = '%s%s' % (esc(first), esc(other)) +if autoescape: +first, other = conditional_escape(first), conditional_escape(other) +result = '%s%s' % (first, other) --~--~-~--~~~---~--~~ 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: Understanding autoescape-aware filters
Malcolm, first of all, I should apologies. I actually intended my letter
being 'funny' but after your answer I understand that it was just harsh
:-(. I'm sorry. And let me again express that I never stopped to wonder
how you manage to do so many great things in Django. Thank you very much!
Still I believe that my dumbness in understanding new filters is a good
use-case to work out since I understand other Django docs well. So here
goes...
Malcolm Tredinnick wrote:
> It's very easy to end up with a result that isn't a SafeData
> instance after a few string manipulations, so this isn't a trivial
> issue. For many filters, the actions they perform won't remove that
> safe-ness in effect, but they won't be a SafeData isntance.
Got it. If I do SafeString('test') + 'test' the result will be a str,
not SafeData.
> So Django
> notes that the input was a SafeData and the function is marked is_safe
> and, thus, it calls mark_safe() on the result so that you don't have to
> in your filter
This is my first misunderstanding. mark_safe seems trivial enough, why
not just use it instead of .is_safe=True on a filter?
Looking at this from template/__init__.py:
if getattr(func, 'is_safe', False) and isinstance(obj, SafeData):
obj = mark_safe(new_obj)
they're essentially equivalent modulo type checking. Why doesn't
mark_safe do type checking itself?
> Because you wouldn't be able to write a filter that worked correctly in
> both auto-escaping and non-auto-escaping environments, which is a
> compulsory requirement in most cases. You don't want to escape inside
> the filter if the current context doesn't have auto-escaping in effect.
Uhm.. This is the second thing I'm missing. I though that {% autoescape
off %} is a backward-compat measure. So .needs_autoescape exists only
for filters that used to do non-safe output and should behave as such in
a non-autoescaped environment. And I thought that in a new era all new
filters and tags actually should *always* return safe values. No?
> I'll have one more pass at it and after that I look forwards to reading
> your patch to improve things.
I will certainly try to do this.
>> For example. I'm writing a filter that gets a string and wraps it's
>> first letter in a I'm going to split the first letter,
>> conditional_escape the letter and the rest, wrap a letter in ...,
>> concatenate and mark_safe. Now, should I stick .is_safe?
>
> If you're always returning a safe string, then adding is_safe is a
> no-op.
Yes, but *should* I always return a safe string? I believe in my case I
really should because I'm returning some HTML and nothing after my
filter could magically decipher it and escape parts of the string that I
didn't escape. Right?
If yes, does it mean that I should use .need_autoescape to know if my
input was already escaped manually (if autoescape is None) or I should
do it myself (is autoescape == True)?
> Remember that I've managed to achieve what you said was impossible in
> your original list of 10 things you hated about Django:
Uhm... Originally it was "'N things I don't like..." and I called it a
"hate-list" as a joke :-). And actual wording about autoescaping was
that "it's now impossible to fix the easy way so it has to be fixed the
hard way". As far as I understand this indeed was hard.
Thanks for your answer!
--~--~-~--~~~---~--~~
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: Understanding autoescape-aware filters
SmileyChris wrote: > It's explained here: > http://www.djangoproject.com/documentation/templates_python/#filters-and-auto-escaping Yes, I've asked the group after I've read those docs, twice :-). First time I thought that I was just slow but the second time I didn't understand again and asked for help... --~--~-~--~~~---~--~~ 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: advice on template shortcomings
Ken wrote: > For instance, I > cant pass a dict or a list of lists to the template. Actually it's not true, you can perfectly pass and access dicts and lists and whatever in templates. Can you describe your specific case that didn't work? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Understanding autoescape-aware filters
Hello! I'm about to convert my apps to play well with recently introduced autoescaping but I have to confess that I don't get mark_safe, is_safe and needs_autoescaping. First, I don't get why .is_safe attribute is needed at all. If my filter returns any HTML I should escape it and mark_safe the result, no? Then, looking at default filters I see that .is_safe is set to False for all filters returning non-string values. Though these values are pretty safe for HTML when they would be converted into strings in the end. And 'needs_autoescape' escapes me absolutely... If I'm dealing with user content and HTML why, again, can't I escape it inside my filter's code and mark_safe it? Anyway... Malcolm (as the main implementer), sorry, but the docs are written in Linux how-to style: "make these magic passes and hope for the best and don't try to understand the thing since you never will". Could you please clarify why are those things needed and what exact effect they are intended to cause? For example. I'm writing a filter that gets a string and wraps it's first letter in a I'm going to split the first letter, conditional_escape the letter and the rest, wrap a letter in ..., concatenate and mark_safe. Now, should I stick .is_safe? Because yes, I think it will return safe output given a safe string. What will break if I didn't (my experiments so far show that nothing breaks). Should I also ask for autoescape parameter and how am I supposed to use it? Ok, this was a bit messy but I honestly thought it should be easier :-) --~--~-~--~~~---~--~~ 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: Using {% ifequal %} in my template is not working
Greg wrote:
> request.session['info'].update(shape=ProductShape.objects.get(id=request['shape']))
> return render_to_response('search.htm', {'pinfo':
> request.session['info']}
This might be because of your first line here doesn't work as expected.
Session is not exactly a dict and one of the things where it differs is
that when you put a mutable object (a list, a dict etc.) into it you
can't change it in place. Instead you should reassign the whole object:
d = request.session['info']
d.update(shape=...)
request.session['info'] = d
--~--~-~--~~~---~--~~
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: ascii decode error bites again
Kenneth Gonsalves wrote:
> ProgrammingError at /web/admin/web/fosscalendar/add/
> ERROR: character 0xe28099 of encoding "UNICODE" has no equivalent in
> "LATIN1" INSERT INTO
> "web_fosscalendar" ("name","year","startdate","enddate","city_id","venue
> ","organiser","scope","website","contact") VALUES ('lll',
> 2007,'2007-11-01','2007-11-01','1','','ll','lll','','Users’ Group')
> Request Method: POST
> Request URL: http://nrcfosshelpline.in/web/admin/web/fosscalendar/add/
> Exception Type: ProgrammingError
> Exception Value: ERROR: character 0xe28099 of encoding "UNICODE" has
> no equivalent in "LATIN1"
Ah... So this is what you called "ascii cannot decode etc" in your
original post? This is an absolutely different issue that has nothing to
do with Python's default usage of ascii for decoding or even Django's
unicode internals.
What happens here is your Postgres database is configured to store data
in Latin 1 encoding. Thus it just cannot store any non-ascii characters,
including that curly single quote. If you want to do this you have to
either encode your data manually into something containing only ascii
characters (like using \u or � escapes) or just convert the
database to be in a more capable encoding (any unicode that that version
of Postgres would support).
--~--~-~--~~~---~--~~
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: Reversing a url with a get parameter
Rufman wrote:
> hey guys
>
> I need a little help reversing urls with a get parameter.
>
> I'm using urlresolvers.reverse() in my view to reverse the url as
> follows:
> reverse(pageName, kwargs={'page' : page})
>
> If i try passing thre request.GET object as so:
>
> reverse(pageName, args=[request.GET], kwargs={'page' : page}
>
> I get the url with the keyword arg but no get args. Apparently it's
> wrong if I pass the request.GET object in args. Does anyone have a
> better idea.
Args and kwargs in reverse are needed to fill the placeholders in your
url. If you have an urlpattern like this:
(r'^objects/(\d+)/$', objects_view)
then you can construct a URL with reverse like this:
reverse('objects_view', args=[obj.id])
... and obj.id will replace (\d+) part.
As for GET parameters, you don't need any special logic that would
format them in some tricky way because they are uniform. You can just do
this:
reverse(pageName) + '?page=%s' % page
--~--~-~--~~~---~--~~
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: why HTML output in unicode?
Ken wrote: > Sorry if this is a stupid question, but why do forms output HTML as > unicode strings? Is this arbitrary or is there some grand convention > we are all supposed to be following? The general convention is that all strings inside your project are supposed to be unicode. They are only serialized in byte string for IO with database or http. > If I construct a page with newforms objects together with > my objects (which dont produce unicode) writing the HTML to a StringIO > object and dumping it out at the end, I don't see unicode. I'm > confused. I'd say the best and most convenient way is to teach you producer part to produce unicode. This is anyway a more universal format for strings. --~--~-~--~~~---~--~~ 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: @url tag - getting rid of urlpatterns
Ilya Semenov wrote:
> Second, I think the use of generic views is over-estimated. Generic
> views do not even support access restrictions (@user_passes_test) and
> thus are most of the time proxied via custom one-line views.
Actually they support decoration perfectly well, right in urls.py:
from django.views.generic.list_detail import object_detail
from some_decorators import decorator
urlpatterns = patterns('',
(r'...', decorator(object_detail), { ... }),
)
Though I agree that generic views require some time get used to...
--~--~-~--~~~---~--~~
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: @url tag - getting rid of urlpatterns
Ilya Semenov wrote:
> === apps/app1/views/__init__.py ===
> @url(r'^index/$')
> def index(request):
> ...
>
> @url(r'^news/$')
> def news(request):
While the decorator looks nice it creates in my opinion at least as many
problems as it solves.
1. You can apply decorators only to custom views, not to generic views.
And as generic views are commonly used one still should keep a separate
urls.py for them.
2. One of the best things (again, in my opinion) of urls.py is that it
shows whole user interface of an app in one place. You loose this
feature with decorators scattered all over views.
BTW, do you know that you can use function objects instead of their
names in url definition? So this:
urlpatterns = patterns(__name__,
(r'^index/$', 'index'),
becomes just:
urlpatterns = patterns('',
(r'^index/$', index),
--~--~-~--~~~---~--~~
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: unicode characters garbled on dumpdata / loaddata using postgres
Wiley wrote: > I was wondering if anyone else had trouble or a workaround for dumping > and loading data with mixed character sets using a postgres backend. > My data has quite a few Chinese characters, they run from my normal > installation fine, but when i dump and reload the data, it's all > corrupted. Any hints here? Are you using latest trunk builds? There were still a couple of problems with serialization in 0.96 release that were fixed on trunk by switching Django to unicode [1]. Now all should work fine. [1]: http://code.djangoproject.com/wiki/UnicodeBranch#PortingApplicationsTheQuickChecklist --~--~-~--~~~---~--~~ 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: Don't Repeat Yourself!
sago wrote: > The feed approach for routing urls is everything that django's url > system was designed not to be: it imposes a hierarchical structure on > the url, distributes the configuration over multiple representations, > and could be avoided by having a feed view that behaves more like > generic views: > > > > Am I wrong to feel this way? Can't say about wrong or not but I certainly felt the same way when I first used the syndication framework. Back then I decided not to worry too much about it but, yes, it would be nicer to have urlconfs behaving like they should in this field also. So it's basically just mine +1 :-) --~--~-~--~~~---~--~~ 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: XML output
Alex Nikolaenkov wrote:
> Hello guys,
> I like just about everything in django, but at this point of me reading django
> book I can't imagine the way of xmlizing django.
There are serializers in Django:
http://www.djangoproject.com/documentation/serialization/
> Is there a way to use XSLT templates instead of standard django template
> language?
It could look something like this (not tested of course :-) ):
from django.core import serializers
from models import MyModel
def my_view(request):
object_list = MyModel.objects.all()
xml = serializers.serialize('xml', object_list)
return HttpResponse(xml, mimetype='application/xml')
--~--~-~--~~~---~--~~
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: Random character in rendered HTML
brutimus wrote:
> {% block content %}
>
> {% include "whatever.html" %}
> {% endblock %}
This is most certainly a BOM -- Byte Order Mark of a UTF-8 charset that
your text editor has added at the beginning of the 'whatever.html'. It's
a part of UTF-8 and those symbols are normally not seen when they are at
the beginning of the string. However here this string is included in the
middle of another and symbols are visible.
It looks like a bug in Django, it should strip BOM when loading utf-8
templates... For now you may try to work around it by trying to set up
you editor to not save a BOM (if it can do this).
--~--~-~--~~~---~--~~
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: Per-domain ROOT_URLCONF and TEMPLATE_DIRS
Jeremy Dunck wrote: > Two settings files being used by a single process? > > How would that work? Oh... I missed the bit about a single process. But now I wonder why require this? One server can happily serve two sites either from separate mod_python handlers or separate FastCGI servers. Vladimir, why do you need a single process? --~--~-~--~~~---~--~~ 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: Per-domain ROOT_URLCONF and TEMPLATE_DIRS
Vladimir Pouzanov wrote: > Hi all, > > I have two sites that run nearly identical django instances. I wonder > if it's possible to somehow set per-domain ROOT_URLCONF and > TEMPLATE_DIRS to serve both sites from one django process. Why not just have two settings files? If you have common settings you can keep them in one file and then import everything from it in each setting file: from common_settings import * # Specific TEMPLATE_DIRS TEMPLATE_DIRS = ( ... ) # Specific urlconf ROOT_URLCONF = ... --~--~-~--~~~---~--~~ 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: Mysql sleeping queries
Malcolm Tredinnick wrote: > Perhaps read the remainder of the thread? :-) Sorry, I was too impatient this time :-) --~--~-~--~~~---~--~~ 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: Mysql sleeping queries
Malcolm Tredinnick wrote: > Thanks, Ilya. I'd gotten that far, too. Unfortunately, though, it isn't > quite that easy. Well, it is that easy for mod_python, however for WSGI > compliance, we can't do that (since the WSGI handler returns an > iterable). But a WSGI server calls "close()" on the iterator after iteration and we support this in HttpResponse. Why not send "signals.request_finished" there? --~--~-~--~~~---~--~~ 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: Mysql sleeping queries
Malcolm Tredinnick wrote: > One other thing that I forgot in my earlier email: it's not actually > clear why the database connections get "lost" in the current > implementation. We close the connection too early, but when the template > rendering needs to access the database, it just opens a new one (that is > why everybody is seeing more opens than closes). However, the next time > that thread or process is used, Django should be reusing the same > connection, since it will still be open and we check for an existing > connection before opening a new one. In case of threads the old thread's connection can't be reused because it is stored in thread.local() and a new thread is new thread. This ad-hoc 'pooling' actually never worked AFAIR... And I suspect that at least under Apache every new request results in a new Python thread both with prefork and worker mpms. --~--~-~--~~~---~--~~ 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: Too many queries generated by ChangeManipulator
Russell Keith-Magee wrote: > On 6/1/07, char <[EMAIL PROTECTED]> wrote: >> Obviously, the performance deteriorates rapidly as the number of >> GamesOfInterest added to a Profile increases. Is there any way to >> avoid this? > > This is a known problem, and one of the many reasons that the forms > framework is being replaced with 'newforms'. > > There is no workaround (that I am aware of), nor are there plans to > fix the (many) problems with the Manipulator framework. Actually this bug affects both old forms and new forms. There is a ticket with a patch fixing the issue: http://code.djangoproject.com/ticket/3436 --~--~-~--~~~---~--~~ 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: ChangeManipulator and default value not working.
[EMAIL PROTECTED] wrote: > Oh..I meant to mention that this is using the default > ChangeManipulator for the class. Then set to the field 'editable=False' and manipulator won't touch it. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Test DB creation parameters
Michal wrote: > It seems like the test database is created in SQL_ASCII encoding. I > looked into psql terminal and found: > > List of databases >Name | Owner| Encoding > -++--- > gr4unicode | pgsql | UNICODE > test_gr4unicode | gr4unicode | SQL_ASCII > > DB gr4unicode was created by me, manually: > >CREATE DATABASE gr4unicode WITH ENCODING 'UNICODE'; > > Database test_gr4unicode was created dynamically by calling ./manage.py test Ah! Yes I've stepped on this one too (wrong collation in my case). I don't know if it could be worked around currently... Looks like we need a way to specify db creation parameters. --~--~-~--~~~---~--~~ 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: Unicode-branch: testers wanted
Malcolm Tredinnick wrote: > The unicode branch, [1], is now at a point where it is essentially > feature-complete and could do with a bit of heavy testing from the wider > community. Switched my site today to the branch. Works like a charm (translations, admin, multilingual content). --~--~-~--~~~---~--~~ 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: LIKE '%something%' custom queries
[EMAIL PROTECTED] wrote:
> I'm reimplementing an in-database tree system and I'm using custom SQL
> queries. I want to use % in LIKE but Django doesn't let me.
>
> The code:
> ##
> def getBranch(table_name, parent_depth, parent_cutLevel, max_depth):
> cursor = connection.cursor()
> cursor.execute("SELECT *, INSTR(level,'0')-1 AS depth,
> INSTR(level,'0')-1 - "+ parent_depth +" AS relativeDepth FROM " +
> table_name + " WHERE level LIKE '"+ parent_cutLevel +"%' AND
> INSTR(level,'0')-1 <= ("+ max_depth +"+"+ parent_depth +") ORDER BY
> level")
> row = cursor.fetchall()
> return row
> ##
The error says that Python tries to replace '%' with parameters but
there aren't any. To escape them duplicate them:
" WHERE level LIKE '"+ parent_cutLevel +"%%' AND ...
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Search options
Hello! I'd like to ask everyone's opinion on implementing a search functionality in an app. The app is a forum that tends to be simple and pluggable. Now I'm on a quest of picking a right solution for searching and have stuck. My current thoughts and decision: - Searching using "like" db queries is too simplistic and tends to be slower over time. - Database-specific solutions (MySQL search, Postgres TSearch2) kill portability. - PyLucene is too large to work in-process (20 MB in memory). Also it doesn't work with Python's threading (segfaulting the whole process on import). A solution would be a dedicated PyLucene process. - Xapian looks good but I didn't actually try it yet. I've heard though that it doesn't implement locking of index database and this should be done manually. Not a rocket science but complicates the solution a bit. I've also seen recommendation to run it in a dedicated process. So my questions are: - Am I doomed to have a separate server? This complicates things a lot and I very much inclined to use some in-process thing - Are there any solutions on a scale between simplistic "likes" and sophisticated indexers like Lucene? --~--~-~--~~~---~--~~ 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: TextInput({'onKeydown': 'some javascript code'} problem
hoamon wrote:
> no.setAttribute("onKeydown", 'Element.update("NO_CHECK", " src=http://mydomain/arrows.gif>");');
Instead of assigning a raw onkeydown attribute it's better to attach an
event. Look into prototype.js' docs, I bet it can do this in a
cross-browser fashion. Something like Event(no, 'keydown', function()
{...}) but I don't remeber exactly...
--~--~-~--~~~---~--~~
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: TextInput({'onKeydown': 'some javascript code'} problem
hoamon wrote:
> how can i customize the fields in the newforms, or i walk the wrong
> way ??
What you described is an issue but I want to advice a different
technique that doesn't suffer from this issue and also considered more
robust.
You shouldn't mix your HTML with Javascript, instead you should assign
Javascript after the fact in a single place. For example:
ID
... and then somewhere in window.onload:
document.getElementById('id_personalid').onkeydown = function() {
// your code
}
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Syntax highlighting
I am developing a non-intrusive javascript syntax highlighter for use in blogs. Recently I've added support for highlighting Django templates and now I feel it can be indeed useful for people writing about Django. Check it out: http://softwaremaniacs.org/soft/highlight/en/ --~--~-~--~~~---~--~~ 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: Implementing OpenID in your Django app
Simon Willison wrote: > Hi all, > > I've just released the first version of an OpenID consumer package for > Django. The idea is to make it ridiculously easy to add OpenID > consumer support to any Django application - and hence allow users of > OpenID to sign in without having to set up a new username and > password. Interesting! Some time ago I've implemented OpenID in my tutorial-like forum app but I took a different approach ([1], link in Russian only, unfortunately). Instead of populating request with '.openid' property I've implemented an auth backend that creates unique Django users and associates them with OpenID. This way users can login with OpenID and then be a first-class citizens in the system (use admin for example). [1]: http://softwaremaniacs.org/blog/2007/03/25/cicero-openid-hcard/ --~--~-~--~~~---~--~~ 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: Variable value in template
Kai Kuehne wrote:
> With this
>
> Team:
> {% for team in object.squad.team_set.all %}
> {% appearance_count_for_team team.id %}
>
> and
>
> class AppearanceCountForTeamNode(template.Node):
> def __init__(self, team_id):
> print team_id
> ...
>
> I get "team.id" printed out and not the id of the team.
> Why doesn't it get evaluated? I don't understand this.
This is because templates are first parsed into a tree (this is when you
node is created) and only then are evaluated against a context. This
will happen in render():
class AppearanceCountForTeamNode(template.Node):
def __init__(self, team_id):
self.team_id = team_id
def render(self, context):
team_id = self.team_id.resolve(context)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Django Set HTTP Error manually
johnny wrote:
> What I want to do is set HTTP Error manually in my view, when a
> request is made to certain url, without post data.
>
> At a particular url, my view is looking for XML document to be sent
> over http, by post. If a request come in without post, I want to
> raise an error "405 Method Not Allowed". How do I do this?
In fact 405 doesn't mean "post without data", you should answer 405 if
you receive anything except 'POST' in HTTP method. This is done by a not
very well-known decorator:
from django.views.decorators.http import require_http_methods
@require_http_methods('POST')
def your_view(request):
...
I think your app should react on an empty POST as it does on any invalid
XML document. I mean just get request.raw_post_data and send it to a
parser as you (presumably) do now. It doesn't matter if it has '' or
'some garbage' there.
--~--~-~--~~~---~--~~
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: Newbie problem with view/model interaction
Ross Burton wrote:
> then in the view:
>
> {% for paper in object_list|dictsort:"title" %}
> {% if paper.has_voted( TODO ) %}
>
Not related to your question, but this is called 'template' in Django.
'View' means a different thing (a controller).
> I then discovered that you can't pass arguments to methods in
> templates, so I can't ask the model if the current user has voted.
I'm sure someone will suggest something less scary for a beginner but I
can now only come up with such a custom template tag:
class IfVotedNode(template.Node):
def __init__(self, paper_expr, node_list):
self.paper_expr, self.node_list = obj_expr, node_list
def render(self, context):
paper = self.paper_expr.resolve(context)
if paper.has_voted(context['user']):
return self.node_list.render(context)
else:
return ''
@register.tag
def ifvoted(parser, token):
bits = token.contents.split()
if len(bits) != 2:
raise template.TemplateSyntaxError, '"%s" takes 1 parameter ' %
bits[0]
node_list = parser.parse('end' + bits[0])
parser.delete_first_token()
return IfVotedNode(parser.compile_filter(bits[1]),node_list)
It's then used like this:
{% ifvoted paper %}...{% endifvoted %}
Docs on creating custom template tags are here:
http://www.djangoproject.com/documentation/templates_python/#writing-custom-template-tags
--~--~-~--~~~---~--~~
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: models.ManyToManyField: Multi-relationship in one table
hoamon wrote: > Course|Trainee|Company > C1| T1 | Com1 > C1| T2 | Com1 > C1| T3 | Com1 > C2| T1 | Com2 > C2| T3 | Com1 > C2| T4 | Com2 > C3| T1 | Com2 You really can't do it using standard ManyToManyField. The common way is to create this relation explicitly: class Record(models.Model): # or whatever name fits course = models.ForeignKey(Course) trainee = models.ForeignKey(Trainee) company = models.ForeignKey(Company) --~--~-~--~~~---~--~~ 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: problem with template {% url string %}
Paul Rauch wrote:
> Template:
> {% url cvh.view.login %}
Here you have "view".
> urlpatterns = patterns('mysite.cvh.views',
> (r'^$','index'),
> (r'^login/$','login'),
> )
And here you have "views". {% url %} doesn't find your pattern and
returns '' (empty string) that browser translates to a current URL.
{% url cvh.views.login %} should do.
--~--~-~--~~~---~--~~
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: low performance of FastCGI deployment
Alexander Boldakov wrote: > Django deployment documentation claims the need of flup as the FastCGI > library. Are there any flup features that Django relies on? Nothing specific. Flup is recommended because it's pure Python and easier to install. Also documentation *strongly* recommends not to serve media files from Django but to use a separate server instead. This is because serving media from a framework will always be slower and should be avoided. I suspect that even your fix with using more faster FastCGI should still fail you when you get more users. The thing is that you will need a separate process for each download and Django process tends to take about 15-20 MB in memory. Multiply this by user count and you get pretty much memory exhausted for just copying bytes into socket. P.S. I was struggling with similar problem last year and made a 2-part writeup that I think you'll be able to read in Russian: http://softwaremaniacs.org/blog/2006/04/18/controlled-download/ http://softwaremaniacs.org/blog/2006/04/18/controlled-download-2/ --~--~-~--~~~---~--~~ 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: {% url %} problem
akonsu wrote: > thank you Ivan, > > the problem with collapsing is that the 'name' parameter in my view > does not get the default value then if the url is empty. Oh... Indeed :-( Then may be just checking the value inside the function is your best bet for this case. --~--~-~--~~~---~--~~ 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: {% url %} problem
akonsu wrote:
> i think the reason is two entries in the urlpatterns with the same
> view. is this a bug?
Well, not exactly a bug but a limitation of "reverse" function that {%
url %} uses to do actual resolving. Incidentally there is a thread in
django-developers[1] about solving a similar issue.
But in your case I believe you can just collapse both url patterns into
one since they point to the same view:
urlpatterns = patterns('',
(r'^(\w+)?/?$', 'path.to.myview'),
)
--~--~-~--~~~---~--~~
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: BooleanField won't update
[EMAIL PROTECTED] wrote: > def update_snip(request): > u = User.objects.get(id=request.session['userid']) > snip = Snippet.objects.filter(id=snippet_id,user=u) > snip[0].active = 0 > snip[0].save() > print "Active = %s" % snip[0].active > > This NEVER works. What am I doing wrong? This is because 'snip' is not a list but a queryset and 'snip[0]' is implemented in a way to just add 'LIMIT 1' to the query. And this query is executed each time when you try to access an attribute of 'snip[0]' thus giving you new fresh copy of the object from database: snip[0].active = 0 # get a snip, set active = 0 snip[0].save() # get a snip from db again and save it This is why 'active' is never saved. Assign 'snip[0]' to a variable and it will work as expected. --~--~-~--~~~---~--~~ 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: getting raw SQL queries
Iapain wrote: > Hello, > > I am writing a SQL logviewer for sql queries fired by django. If I use > below code then i get an empty list of dictionary. > > from django.db import conneciton > from django.conf import settings > debug = settings.DEBUG #btw its always True, because i set it to true > in my settings.py > settings.DEBUG = True > print str(connection.queries) Where is this code located? A common error is to place such logs in a view before rendering a response while many queries happen during response generation from templates. Your best bet is to put this logic in a response middleware and place it last. --~--~-~--~~~---~--~~ 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: select_related() and null=True
Ilya Semenov wrote:
> What different approach could I choose? I'm writing real-life model -
> a Ticket can either have a User (who resolved it), or not (if the
> ticket has not been yet resolved). Listing all resolved Tickets with
> corresponding Users is a simple real-life task, too.
Indeed... However Django does not implement it as of now. It would be
fine if you create (or just find) a ticket on this issue in Django Trac
(http://code.djangoproject.com/). Note, though, that the code dealing
with query construction is undergoing a heavy refactoring so it may take
a while to implement this behavior.
> How do I find a different approach? The only solution which comes to
> my mind is to create a "special" User with id=0, and make all None
> references point to it instead, but this seems very unnatural and
> hackish to me.
I'd suggest to do just this (not exactly with some special id but with
some special username). This is, in fact, one of the classic
refactorings from M. Fauler's book -- "Introduce NULL object". In short,
having an object that acts as "nobody", "nothing", "not initialised" etc
is more convenient than having the field just NULL because then there
are far less places where you should do NULL checks.
For example (simplified) you can set username to "nobody" and in a
template write:
{{ ticket.user }}
instead of:
{% if ticket.user %}{{ ticket.user }}{% else %}nobody{% endif %}
--~--~-~--~~~---~--~~
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: Persistent connections
[EMAIL PROTECTED] wrote: > Is this truly the case? I thought Django used a persistent db > connection. No, Django closes connections upon each request. There were some discussions about it in the early days and some consensus was along the lines that a simple ad-hoc solutions like "just don't close connections" wouldn't suffice and it's better for the user to use solid external tools. pgpool is an example of such a tool for Postgres and there is also SQLRelay that works for many DBs. --~--~-~--~~~---~--~~ 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: installation-wide fixed language
omat * gezgin.com wrote: > Yes, but I want the application to be internationalized. I want only > one of the installations to have only one translation. I had this problem on my site. I don't know if it's a bug or not but I managed to make it work by choosing English as a default language and Russian (in my case) as a translation. As I understand, with gettext you can't have exactly one language because it has separate concepts of a default language and translations. --~--~-~--~~~---~--~~ 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: unicode in filters
Dirk Eschler wrote:
> you can try to add this as first line in your file:
>
> # -*- coding: utf-8 -*-
And after this there's no need to write u'ç'.encode('utf-8') but is
enough to write just 'ç'.
--~--~-~--~~~---~--~~
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: {% url %} syntax in templates
omat * gezgin.com wrote:
> And url pattern that matches the view is
> (r'^photo/(?P[-\w]+)/(?P\d+)/$',
> 'artist.views.artist_photo'),
>
> Images are displaying fine but the links does not appear. (i.e. {% url
> artist.views.artist_photo slug=artist.slug,id=photo.id %} does not
> render anything.
>
> Do you have any idea what is wrong with my syntax?
The syntax is correct, I just got it working on my machine. Things to check:
- Does your template's context actually contain an object 'artist' with
a non-empty slug? Non-empty because your url pattern expects it this way.
- Is photo.is is a number?
- What is the first parameter in your patterns() that contains this
pattern? It it's not empty then the actual view name will be
concatenated after that prefix.
- Is this urlconf file included in the root urlconf? E.g. does your
project find a URL like /photo/something/1/ ?
> Also I think this syntax works only if the view is defined as a string
> in the urls.py. Is this true?
No, it works with callable views just fine.
--~--~-~--~~~---~--~~
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: Model instance identity
David Abrahams wrote: > I just wrote some code that used Model instances as keys in a dict, > and was surprised to find two instances in the dict that represented > the same object in the database. Shouldn't that be impossible? If > you can't guarantee that a given object in the database is always > represented by the same Python instance, shouldn't django.db.Model > have __hash__ and __eq__ methods that makes equivalent instances hash > the same? This is a known issue: http://code.djangoproject.com/ticket/2936 The ticket was closed as "invalid" with a good reason (model instances are mutable and shouldn't be used as keys in dicts). --~--~-~--~~~---~--~~ 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: Having trouble with my M2M relationship.
[EMAIL PROTECTED] wrote:
> sponsor = models.ManyToManyField(Sponsor,
> filter_interface=models.HORIZONTAL, related_name="section")
>
>
> What I'm trying to do in a template is show all the sections that
> sponsor is in. It seems to me I should be able to do something like
>
> {% for section in sponsor.section_set.all %}
You have specified related_name="section" which is the name that will be
used instead of default section_set. So it should be sponsor.section.all
in your case
--~--~-~--~~~---~--~~
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: IPython Shell does not see database changes made by views.
Paul Childs wrote: > I wanted to do some checks through the shell, which I was opened > during my unit testing, and found that after making some queries using > Django objects there appeared to be no changes in the database. When I > checked the database using its admin tool the changes were there. This sounds like caching in querysets. When you do things like this: objects = Model.objects.all() for obj in objects: print obj The 'objects' once evaluated don't look into database again, it keeps the result itself. To query database again just create a new queryset from the Model's manager: objects = Model.objects.all() I.e. each 'Model.objects.something...' will create a fresh queryset that will query database again. --~--~-~--~~~---~--~~ 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: Euro Sign raise UnicodeEncodeError
Christian Schmidt wrote: > Do I have to encode (or decode) the string before I put it into the > database First, it depends on database backend. As far as I know MySQL wants byte strings (and for example psycopg2 lives happily with unicode strings). If you use newforms then you have data in unicode and you should then encode it to put into db. If you don't do this explicitly Python will use whatever default encoding is set for this in your environment. It's latin-1 in your case and it can't encode "", this is why you get an error. The next question is which charset to use for encoding. This depends on setup of your database. If it's configured to store data in utf-8 that can encode all unicode characters (meaning in practice just all characters) then you just encode your unicode strings into utf-8 and all will work just fine. If the database configured in some 'old school' way using a legacy charset then things get more complicated (can this charset also store ""? can this database accept utf-8 even if it doesn't recognize it as such? do you need sorting? will anyone else use this database with other client software?). To summarizes: your storage (a database) and your input/output (the web) really should use utf-8 to avoid problems with "strange" characters. If you deal internally with unicode (which newforms produce for you) then for now you should explicitly encode from it to utf-8 until Django starts doing it automatically. --~--~-~--~~~---~--~~ 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: how to list all Tags for Blog? or simple m2m filtering...
natebeaty wrote: > ..but apparently this will only populate the tags once, when I start up > Django, correct? Do I need to add the extra_context in a wrapper around > a generic view in views.py? Or would something like this be best > implemented as a template_tag? > > Am I correct in assuming it would be best to use a template_tag if it's > needed across many views, but otherwise easier to just populate the > template w/ extra_context? Apart from these two ways of working around views there is also a 'template context processor' thingy. It's like extra_context but not static. It's a custom function returning context dict that is called for every view (well not exactly every view but it doesn't matter for now, for generic views it works). Docs are here: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext To summarize. You can put your logic in urls.py, in a template tag, in a context processor, in a wrapper around generic view or in a custom view. What to choose is very much depends on your application and how you feel is better. Some subtle differences that I rely on: - context processor is for 'global' vars that you need almost everywhere in templates - template tag is a more complex logic that just a vars and it also should be useful in many templates - extra_context is a dumb data (no logic) for configuring certain generic views, not the whole site - wrapper around a generic is same as extra_context but if you need some logic - custom view is a custom view :-) --~--~-~--~~~---~--~~ 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: how to list all Tags for Blog? or simple m2m filtering...
natebeaty wrote: Tag.objects.filter(blog__id__isnull=False) Perfect! Yeah, "all tags that have relation to any blog" -- that's what I was trying to say! Actually I've forgot 'distinct' yet again: Tag.objects.filter(blog__id__isnull=False).distinct() ...or there would be dupes in the result. --~--~-~--~~~---~--~~ 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: how to list all Tags for Blog? or simple m2m filtering...
natebeaty wrote: SELECT t.value FROM `blog_blog_tags` b LEFT JOIN `tags_tag` t ON (b.tag_id=t.id) but that feels like cheating.. besides, I'd like to better understand the ORM. Ah... You mean "all tags that have relation to any blog". This is it: Tag.objects.filter(blog__id__isnull=False) This is less hackish than row SQL :-). Reference to 'blog' effectively joins Tags and Blogs. id__isnull=False is a bogus condition that is always true and is needed only to satisfy syntax. There is no such explicit thing as "just join" in Django's ORM. Though given that I'm writing this a second time for the last month may be it should :-) --~--~-~--~~~---~--~~ 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: how to list all Tags for Blog? or simple m2m filtering...
natebeaty wrote: I'd like to throw this in as extra_context along the lines of: "tag_list" : Tag.objects.filter(this_is_where_my_brain_is_shorting) This is in fact pretty standard Django ORM, nothing special to TagsField: blog.tag_set.all() (assuming blog is an instance of Blog). You can also filter it as you wanted going from Tag models: Tag.objects.filter(blog__pk=blog.id) ... but this feels to me somewhat backwards. --~--~-~--~~~---~--~~ 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: Design Q: Foreign keys from object.values()
[EMAIL PROTECTED] wrote: > Thanks; this works for me -- though I have to do > > Author.objects.filter(story__id__isnull=False).distinct() > > Or it repeats each author for each of his stories. > > This still confuses me, because there is no "story" field in the Author > model to specify how to do the join (Author:Story is One:Many, so I > just put a foreign key in the Story model). I guess it is inferring > the Join conditions by looking at the Story model. But what if I had > two Story-Author relations, say: > > class Story (models.Model) : > author = ForeignKey(Author) > editing_author = ForeginKey(Author) > > How could it possibly know which one I wanted to join on? When specifying more than one ForeignKeys to a model Django requires you to explicitly specify related names for master-to-child relations: class Story(models.Model): author = models.ForeignKey(Author, related_name='stories') editor = models.ForeignKey(Author, related_name='edited_stories') Then you do: Author.objects.filter(edited_stories__id__isnull=False).distinct() This related_name is also used for related managers: author.edited_stories.all() --~--~-~--~~~---~--~~ 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: Design Q: Foreign keys from object.values()
[EMAIL PROTECTED] wrote:
> Hi guys,
>
> I'm trying to get a better grip on Django design philosophy, and I'm a
> little confused as to why calls to a manager's " values() " function
> returns foreign keys as the value of their primary key rather than as
> django objects. For example:
>
> class Author (models.Model) :
> name = CharField(maxlength=100)
> class Story (models.Model) :
> author = ForeignKey(Author)
>
> "Story.objects.values('author').distinct()" returns a set of
> dictionaries whose values are Author.id 's instead of the actual Author
> objects. I then have to Author.objects.get(id) for each id, which
> seems like the sort of boilerplate code Django usually avoids.
>
> Am I missing a better way of doing this, or a reason it *should* work
> this way?
Yes, values() is intended to work this way. But this is not a common
thing to do. You want to use values() in some special cases where you
really need a list of dicts. If what you need is set of Author objects
that have Stories this is it:
Author.objects.filter(story__id__isnull=False)
What happens here is that 'story__id' joins Authors with Stories
effectively filtering Authors that have this relation. And isnull=False
is just a meaningless part that is always true needed to satisfy the
query syntax.
--~--~-~--~~~---~--~~
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: Hi! Here's a new Django beginner with a few questions.
Sebastien Armand [Pink] wrote:
> class Person(models.Model):
> ...
> mother = models.ForeignKey('Person')
> ...
>
> Will this work?
Use models.ForeignKey('self')
> For example if I've got a Body class and a Legs class, I know that I'll
> never have a body with more than 2 legs
Did you know about mutation? :-)
> and it would be easier to have a
> leftLeg = ForeignKey(Leg) field
> and a
> rightLeg = ForeignKey(Leg) field
>
> but this causes many errors when I try to validate my model.
Upon seeing a ForeignKey Django tries to create backward accessors from
the parent model to children. In your case it should be "Leg.body_set"
that will fetch all Legs with a ForeignKey to a particular Body.
However since you have two ForeignKeys to the same model Django needs to
have two such relations: all bodies for a LeftLeg and all bodies for a
RightLeg. The only problem that it doesn't know how to _name_ these
relations. It certainly can't have two different "body_set"s on a Leg.
So the only thing that it asks you is to choose two names for the relations:
leftLeg = models.ForeignKey(Leg, related_name='bodies_if_left')
rightLeg = models.ForeignKey(Leg, related_name='bodies_if_right')
My naming skills are known to be lousy so choose your own according to
what these things really mean.
--~--~-~--~~~---~--~~
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: Inner Join
Russell Keith-Magee wrote: table1.objects.filter(table2_attribute_name.field='foo') Did you mean table1.objects.filter(table2_attribute_name__field='foo') (i.e. '__' instead of '.')? --~--~-~--~~~---~--~~ 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: Extending ManyToMany managers
Gulopine wrote: Yeah, I guess I see the biggest obstacle here is the simple fact that the ManyToMany manager is generated each time it's referenced, rather than persisting on the model. I can replace the add() method of the generated manager to get it to work immediately, but the next time I retrieve the manager, I get back the default one. I also hit this once when I need to generate a signal each time a contents of an m2m relation changes. This on-the-fly generation really looks weired in this place. I fail to see the purpose of it. --~--~-~--~~~---~--~~ 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: dynamically changing URLS
James Bennett wrote:
However, in your specific case I wonder if it wouldn't be better to
just have a separate settings file
Another approach (simpler in my view) is to have a middleware like this:
class EmergencyMiddleware:
def process_request(request):
return render_to_response('emergency.html', {})
And comment/uncomment it in the settings file when needed:
MIDDLEWARE_CLASSES = (
# myproject.middleware.EmergencyMiddleware,
...,
...,
)
--~--~-~--~~~---~--~~
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: Types of projects Django is not well suited for?
Kenneth Gonsalves wrote: that has already been answered in the django documentation. Django is not a tool for endusers to create quicky web applications. It is not a ready made CMS/blog/BBs etc. I didn't say anything like this. Your question was why we would list Django's restrictions. I replied that this is 1) polite 2) very logical since we are here know best what Django is not suitable for. --~--~-~--~~~---~--~~ 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: Types of projects Django is not well suited for?
Kenneth Gonsalves wrote: Why on earth would any web framework make a list of web apps that it is not suitable for? To be kind to a potential user when he might acquire a need to do something the framework *is* suitable for. No framework can do everything. And what is the best place to ask about frameworks restrictions than the framework's own maillist? The whole idea of any web framework is to make it suitable for all web apps. This is kinda impossible... IMHO. --~--~-~--~~~---~--~~ 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: How would you implement this?
Eric Floehr wrote: How would you recommend having the first table go against context variable 'table' and the second go against 'secondtable' (for example)? You're looking for inclusion_tag: http://www.djangoproject.com/documentation/templates_python/#inclusion-tags --~--~-~--~~~---~--~~ 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: CSS Basics
Fredrik Lundh wrote: are you trying to say that Django's static server doesn't filter the URL before adding it to the document root ? Sure it doesn't. Mainly because there is no such thing as "Django static server". That view is just a debugging shortcut to let people develop a site when they can't run a separate HTTP server on their machine for some reason. I cannot recall ever seeing a HTTP server that didn't attempt to handle this, and I've never heard of a static HTTP server developer that hasn't treated a failure to handle this as a critical security hole. This is exactly what that "big fat warning" in the docs is about :-). --~--~-~--~~~---~--~~ 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: Duplicate Related Records
Ned wrote:
> ==Template==
> {% for status in form.status %}
>
>
> {{ status.date }}{% if status.date.errors %} class="error">{{
> status.date.errors|join:", " }}{% endif %}
>
Somewhere in the first include {{ status.id }}. It's a hidden field
that actually differentiates existing rows from new ones.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Catching m2m chnages
Hello! I have two models linked through m2m relation. I want to hook a code that will be executed on each change in this relation (adding and removing). If it wasn't about m2m then I would just override a save() method of a model but with m2m an intermediate table is not represented as a model at all. As far as I can see there is nothing in Django for this thing. May be some also had this problem and solved it? --~--~-~--~~~---~--~~ 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: Anonymous Sessions
[EMAIL PROTECTED] wrote: > It is a problem. It hits the db if it has to create it. Sorry I still don't understand :-). You say that you do need authentication but don't need anonymous sessions. Then in default Django setup you never hit a database unless you try to store something in session. So you can check if you work with authenticated (non-anonymous) user and hit session only then: def some_view(request): if request.user.is_authenticated(): request.session['last_login'] = datetime.now() ... return ... Am I thinking in a wrong direction? --~--~-~--~~~---~--~~ 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: Anonymous Sessions
[EMAIL PROTECTED] wrote: > Well we obviously need authentication, we just don't need anonymous > session handling. Then it shouldn't be a problem. Sessions are created and hit db only if you store something in it. Or if you have SESSION_SAVE_EVERY_REQUEST = True. Otherwise request.session is just an empty dict created in memory. --~--~-~--~~~---~--~~ 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: Anonymous Sessions
[EMAIL PROTECTED] wrote: > I'd like a simple option to disable this, any plans to implement > something of the sorts? The intended way is to remove SessionMiddleware and those depending on it (AuthenticationMiddleware) from MIDDLEWARE_CLASSES and 'django.contrib.sessions', 'django.contrib.auth' from INSTALLED_APPS in your settings. --~--~-~--~~~---~--~~ 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: can't figure out how to call a generic view inside my own view
Anton Daneika wrote: > Hello, everyone. > > I am trying to call django.views.generic.list_detail.object_list from my > own view, but I get the error page saying "dict' object has no attribute > '_clone'" > > Here is the function: > def my_gallery_listing(request, gallery_id): > d = dict(queryset=Photo.objects.filter(gallery__pk = gallery_id), > paginate_by= 2, allow_empty= True) > django.views.generic.list_detail.object_list(request, d) The info_dict that you usually construct in urlconf is not intended to be passed to a generic view "as is". It has to be converted into keyword arguments which in Python is done with '**': return django.views.generic.list_detail.object_list(request, **d) This is equivalent to: return django.views.generic.list_detail.object_list(request, queryset=Photo.objects.filter(...), paginate_by=..., allow_empty=) When you pass it without converting as a single argument `object_list` thinks that `d` is its first parameter where it expects a queryset and calls `_clone` on it. --~--~-~--~~~---~--~~ 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: using manipulators without defining fields again
Milan Andric wrote: > I have a long application form for a workshop (name, employment, > resume, ... 65 fields). The user logs in to the site via > django.contrib.auth.view.login, standard django fare. Then the user is > allowed to apply for workshop xyz. If the user clicks save but does > not complete the form, errors are shown and the user gets a message > explaining the incomplete state of the form, but the form data is also > saved in the database, just flagged with complete = 0. Only when the > form validates does Application.complete field get set to 1 so > reviewers know to look at it. I think you don't even have to hack a manipulator... You just define all needed validators and then in a view you can do this: # get data and errors data = request.POST.copy() errors = manipulator.get_validation_errors(data) manipulator.do_html2python(data) # save data regardless of errors object = manipulator.save(data) # show results to a user if errors: object.complete = False object.save() else: return HttpResponseRedirect(...) > What other problems might I run into by disregarding > manipulator.get_validation_errors and saving anyway? This approach doesn't distinct between absent data (which is ok) and broken data (which is not). I could think of such a hack: you get standard validation errors then set all fields in the manipulator as not required and get validation errors one more time. This way you will get only critical errors: errors = manipulator.get_validation_errors(data) for field in manipulator.fields: field.is_required = False critical_errors = manipulator.get_validation_errors(data) --~--~-~--~~~---~--~~ 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: How to default checkboxfield in customer manipulator
jeffhg58 wrote:
> I am trying to set the checkboxfield default value to checked but not
> sure how you do it.
>
> Here is my formfield for the checkbox
>
> forms.CheckboxField(field_name="current"),
>
> I tried ading checked="checked" but that did not work.
It's a bit non-obvious... The actual data to display is provided by a
method called `flatten_data` that is then used to create a form
like this:
data = manipulator.flatten_data()
form = FormWrapper(manipulator, data, errors)
(This is how generic views work and how custom views should be written).
So you have to provide this method in your manipulator returning a dict
with prefilled values:
def flatten_data(self):
return {
'current': True,
}
--~--~-~--~~~---~--~~
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: i18n & server_name
Alexander Solovyov wrote: > Sorry, I found answer - META['HTTP_HOST']. :) Documentation keeps > silence about this. :( Another way is to use 'sites' app and keep domain in a table separately for each site. --~--~-~--~~~---~--~~ 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: File downloads
marksibly wrote: > I couldn't find a 'HttpResponseStaticFile' class or anything, so what > other options do I have? You can pass an open file to a usual HttpResponse: f = open(filename, 'rb') return HttpResponse(f, mimetype='application/octet-stream') > Also, how efficient would it be to send a file via python? In general not efficient at all. Web servers are specifically optimized to give out static files and every solution involving loading and initializing code would be slower. However it may still be acceptable depending on your needs. > What I kind of need is something like a 'private redirect' - ie: I want > apache to do 'serve' the file, but I don't want the client to know > about the redirect. With Apache and mod_python you can use Django for doing authorization and leave the actual file serving to Apache: http://www.djangoproject.com/documentation/apache_auth/ --~--~-~--~~~---~--~~ 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: Calling model-functions in template
Kai Kuehne wrote: > models.py: > def genres_title_list(self, separator=', '): > return separator.join([x.title for x in self.genres]) If I reconstruct the case correctly and `genres` is a relation to child objects with ForeignKey to a Movie then `self.genres` by default should look like `self.genre_set.all()`. Otherwise it will raise an exception (because there is no `self.genres`) and the template system won't show anything there. --~--~-~--~~~---~--~~ 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: Auto-login with REMOTE_USER
Brian Beck wrote: > I don't understand how this is related to the admin interface. Admin interface won't display a login page if you already have request.user set to an existing user. (if I'm not mistaken :-) ). > Anyway, > shouldn't it go after the standard auth middleware, so that > django.contrib.auth.middleware doesn't clobber the request.user that > the middleware posted above sets? Uhm... Yes you're right :-) --~--~-~--~~~---~--~~ 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: Auto-login with REMOTE_USER
Brian Beck wrote: > I just wanted to add that if you want to use this method in combination > with the bundled admin interface, you're gonna have to intercept any > admin requests and do the authentication ... which is achieved by placing this middleware before standard auth middleware. --~--~-~--~~~---~--~~ 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: Auto-login with REMOTE_USER
Ivan Sagalaev wrote:
> request.user = User.objects.get_or_create(
>username=username,
>defaults={...})
This one should be:
request.user, created = User.objects.get_or_create(...)
`get_or_create` returns an object and a flag if it was newly created.
--~--~-~--~~~---~--~~
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: Auto-login with REMOTE_USER
dchandek wrote:
> I've looked at authentication backends and middleware, but it looks
> like the default Django installation expects users to login through a
> Django form.
Default system insist on storing logged user credentials in a session
(though they can be of any nature). In your case you would have to
create your own middleware. Which is quite simple:
class RemoteUserAuth:
def process_request(request):
from django.contrib.auth.models import User
username = request.META['HTTP_REMOTE_USER']
request.user = User.objects.get_or_create(
username=username,
defaults={...})
`defaults` are values for creating new user, refer to User model for
available fields.
You are not even bound to use a built-in User model however it's
recommended because with it you get some little nice things like user
messages, permissions etc.
--~--~-~--~~~---~--~~
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: using manipulators without defining fields again
Milan Andric wrote: > I was told in IRC to extend AutomaticManipulator. But I don't really > know what this means in terms of Django/Python code. Basically you create a manipulator class inherited from an automatic manipulator of a model. It will create all the needed FormFields based on model's fields in `self.fields` list. Then you can: - add your own fields to this list - change existing fields - remove existing fields - overwrite common manipulator methods `flatten_data`, `get_validation_errors`, `save` The main point of such exercises is to get ready-made FormFields if you already have a model defining them. If your form looks like a union of many models or just a custom set of fields this approach won't gain you much. > Does anyone have > an example? To not invent an artificial example could you describe your task in more detail? --~--~-~--~~~---~--~~ 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: [validators] - access to object.id field
Marcin Jurczuk wrote: > Hello, > I'm writing my own validator based on shipped with django and wondering > how get validated object.id field ? Validators come in two varieties: those linked to field definitions in models and those that linked to field definitions in custom manipulators. With first kind you can't get the object's id. They just deal with plain data. The second kind is more flexible since you can write your manipulator as you like it. For example: class MyManipulator(MyModel.ChangeManipulator): def __init__(self, object_id): MyModel.ChangeManipulator.__init__(self, object_id) # add new validator to some field's validators fields[2].validator_list.append(self.validate_field) def validate_field(self, data, all_data): self.original_object # this is the object The main disadvantage of this approach is that you can't use it with generic views since they won't use your custom manipulator. I remember that some was trying to solve this problem on this list but don't remember results of the effort. --~--~-~--~~~---~--~~ 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: import problems?
[EMAIL PROTECTED] wrote: > Sorry if this is poorly explained, but how do you efficiently get > around circular dependency problems like this in Python? I'd hate to > have to drop my import of functions_db to the individual methods on > "Object" to avoid whatever collision is happening. Another (in fact, the opposite) solution is to place imports of your model file locally into those functions_db functions that need it. It looks like your functions_db is a package of utils that intended to be used around the codebase and it's better have as less global dependencies as possible. And another general approach is to logically divide one of the modules in two parts to break circular dependencies: functions_db part needed in Object | +-- Object | +-- second part of functions_db --~--~-~--~~~---~--~~ 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: best place to put dispatcher.connect code?
Le Roux Bodenstein wrote: > Surely if I put it > in a model or a view or whatever somewhere it will only be called the > first time that module gets loaded? The settings module is always imported so you can import your handling code there and put dispatch.connect beside the handling code. --~--~-~--~~~---~--~~ 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: manage.py webserver
[EMAIL PROTECTED] wrote: > Now with django, I am trying to run through the "Are you generic" > tutorial. When I go out to the URL, I get a 404 "Page not found" > message, but absolutely no more information as to where to look! I > thought by using the devel version with the verbosity flag, it would be > able to show me something more, but nope! I suspect you hit one small Django controversy. The generic view object_list would give you 404 error when the list it tries to show is empty. The view is there, it works, finds the list -- all is Ok. It just has this strange behavior by default. To overcome it you can add allow_empty: True to its infodict. BTW usually error messages in Django are super-verbose and super-informative showing you all the places in code involved in error condition complete with local variables. --~--~-~--~~~---~--~~ 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: How to get request.user in templatetag?
Rob Hudson wrote: > The place I need it is the: > class CommentFormNode(template.Node): You probably need it in this node's 'render' method. There you have a context passed to it and this context is exactly the thing that holds all the variables including 'user'. So this is it: class CommentFormNode(template.Node): def render(self, context): context['user'] # this is it --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
