Re: semicolon separated parameter gets inaccessible in QueryDict
Hi, On 26 August 2010 09:56, k4rlchen wrote: > GET /order?asdf=1;2;3;4; In terms of HTTP this query is the same as: GET /order?asdf=1&2&3&4& and Django parses quesry strings accordingly to the HTTP specification. This is consitent with cgi.parse_qs(), so you should probably fix your application. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: static files
On 30 August 2010 20:26, Bradley Hintze wrote: > Hi all, > > I have my site on a production server (apache) and am trying to get > static files to be served but cannot get it to work (serving on the > same server). Following the django documentation did not work, I > edited the httpd.conf as described in the documentation but when I > tried to restart the server the server quit and would not restart. The > error log did'nt give any info as to why. > > I tried this (http://oebfare.com/blog/2007/dec/31/django-and-static-files/) > which is very similar to the Django documentation but I get the same > results as described above. > > Here are my httpd.contf settings. > > #Serving media files for django > > SetHandler python-program > PythonHandler django.core.handlers.modpython > SetEnv DJANGO_SETTINGS_MODULE mysite.settings > PythonDebug On > > > > SetHandler None > > > Alias /site_media/ > /Users/bradleyhintze/djcode/production/MolProbity_Compare_test/media > > SetHandler None > > > WSGIScriptAlias / > /Users/bradleyhintze/djcode/production/MolProbity_Compare_test/apache/django.wsgi > > /Users/bradleyhintze/djcode/production/MolProbity_Compare_test/apache> > Order deny,allow > Allow from all > > > Any help would be appreciated. > > Thanks > > -- > Bradley J. Hintze > Graduate Student > Duke University > School of Medicine > 801-712-8799 > It looks like your trying to use both mod_python and mod_wsgi on the same path ? -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django magic: context passed to template
On 8 September 2010 22:15, maroxe wrote: > Hi, There is something i don't get in django template system. I have a > FileField in my model called myfile. If i pass an instance of my model > to a template, i can access file.size (this is an example). Form where > this variable 'size' come from?? it's not part of the FileField class > as far as i know. A small test: > > def save(self): > super(UploadItem, self).save() > import logging; logging.debug(file.size) > this snippet generates this error: type object 'file' has no att FileField returns a wrapper around File which has a size attribute [1]. In your template you're accessing that field. In your python code you're trying to take "size" from a built-in type "file". To get the value of the "file" field from your model you should use "self.file". Unlike in some other OO languages, object attributes in methods are not implicit. [1]: http://docs.djangoproject.com/en/dev/ref/files/file/#django.core.files.File.size -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: request object in generic view?
On 9 September 2010 05:46, akcom wrote:
> Is there anyway to access the request object from a generic view?
> Specifically, I'd like to access the request.user object. I tried
> doing it as follows:
> (r'^$', 'django.views.generic.simple.direct_to_template', {'template':
> 'index.html', 'extra_context' : {'request' : request}}
> hoping that the dictionary element would be evaluated within the
> context of the view where request would be valid.
That would surely be too much magic.
>Alas I was mistaken.
>
> Any help would be much appreciated!
>
Generic views use RequestContext[1] as the context instance, so all
your context processors are executed. Just add
"django.core.context_processors.request"[2] to your
TEMPLATE_CONTEXT_PROCESSORS list and you'll have the "request" object
available in all your templates
[1]:
http://docs.djangoproject.com/en/dev/ref/templates/api/#subclassing-context-requestcontext
[2]:
http://docs.djangoproject.com/en/dev/ref/templates/api/#django-core-context-processors-request
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Django webiste down
Is it only me or is http://docs.djangoproject.com/ down? -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How to specify NULL as the default of a model field.
Are you adding the field to the model or is the field is already there and you're just adding null=True to it's definition. In the second case, the *backwards* migration will require a default value for instances that have NULL value. On 10 October 2010 00:49, Tim Diggins wrote: > Yes I'm setting blank=True and null=True. But, when I migrate using > South (I've added this field to an existing model), South complains > that the field has no default value... In this instance, it isn't that > important, but just wondering how I specify "NULL" in python in future > (I would normally guess None, but that won't help in this instance).. > Although it's not important I wondered how I can indicate to South > that the default value IS actually NULL - but maybe this is a South > question not a Django (core) question. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Add message on specific error to 500 page
On 11 October 2010 18:54, Streamweaver wrote: > I'm still looking into this if anyone has any insight. > > On Oct 7, 2:04 pm, Streamweaver wrote: >> On our 500 error page I would like to display a message specifically >> if the error is in the Database connection, and not display the >> message on any other uncaught exception but I can't seem to figure out >> a way to catch the specific exception going to a 500 page. >> >> Has anyone done this? You can process the exception using a middleware[1], so that you can later access it's type in your custom 500 handler[2]. [1]: http://docs.djangoproject.com/en/dev/topics/http/middleware/#process-exception [2]: http://docs.djangoproject.com/en/dev/topics/http/views/#the-500-server-error-view -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: login_required and new class based views
On 19 October 2010 19:06, Valentin Golev wrote: > Hello, > > I'm trying to start using new class based views from the trunk. > > I need to rewrite a view which is decorated > django.contrib.auth.decorators.login_required. > > How should I go with that? There are couple of options. 1) decorate the final view (for use in urls.py): decorated_view = login_required(MyView.as_view) In this option, you lose the ability to subclass the decorated view. 2) decorate the dispatch method. You need to turn login_required into a method decorator first (Django should probably provide a tool for this). Here[1] is an example how to do this. class MyDecoratedView(MyView): @on_method(login_required): def dispatch(self, *args, **kwargs): # do any extra stuff here return super(MyDecoratedView, self).dispatch(*args, **kwargs) 3) Make a class decorator, that does the above, so you could do: @on_dispatch(login_required) class MyDecoratedView(MyView): pass > > I was going to write something like LoginRequiredMixin, but I have no > idea how to do this. I need to run my code before .dispatch(), but I > also have to call the old dispatch, but since Mixin aren't inherited > from View, I can't just override method and use super(). This is option #4. You can just do: class LoginRequiredMixin(object): def dispatch(self, *args, **kwargs): bound_dispatch = super(LoginRequired, self).dispatch return login_required(bound_dispatch)(*args, **kwargs) [1]: http://www.toddreed.name/content/django-view-class/ -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: login_required and new class based views
On 19 October 2010 21:21, Valentin Golev wrote: > Thank you! > > Does python's super really works the way like in the last option? Yes, it should call dispatch() from the next class in MRO. So if you place it at the start, like this: class MyView(LoginRequiredMixin, TemplateView): pass It should work as expected. > > -- > Best Regards, > Valentin Golev > Lead Developer > r00, http://r00.ru > > http://valyagolev.net > +7 921 789 0895, avaiable 12:00-18:00 MSK > > > > 2010/10/19 Łukasz Rekucki : >> On 19 October 2010 19:06, Valentin Golev wrote: >>> Hello, >>> >>> I'm trying to start using new class based views from the trunk. >>> >>> I need to rewrite a view which is decorated >>> django.contrib.auth.decorators.login_required. >>> >>> How should I go with that? >> There are couple of options. >> >> 1) decorate the final view (for use in urls.py): >> >> decorated_view = login_required(MyView.as_view) >> >> In this option, you lose the ability to subclass the decorated view. >> >> 2) decorate the dispatch method. You need to turn login_required into >> a method decorator first (Django should probably provide a tool for >> this). Here[1] is an example how to do this. >> >> class MyDecoratedView(MyView): >> >> �...@on_method(login_required): >> def dispatch(self, *args, **kwargs): >> # do any extra stuff here >> return super(MyDecoratedView, self).dispatch(*args, **kwargs) >> >> 3) Make a class decorator, that does the above, so you could do: >> >> @on_dispatch(login_required) >> class MyDecoratedView(MyView): >> pass >> >>> >>> I was going to write something like LoginRequiredMixin, but I have no >>> idea how to do this. I need to run my code before .dispatch(), but I >>> also have to call the old dispatch, but since Mixin aren't inherited >>> from View, I can't just override method and use super(). >> >> This is option #4. You can just do: >> >> class LoginRequiredMixin(object): >> >> def dispatch(self, *args, **kwargs): >> bound_dispatch = super(LoginRequired, self).dispatch >> return login_required(bound_dispatch)(*args, **kwargs) >> >> >> [1]: http://www.toddreed.name/content/django-view-class/ >> >> -- >> Łukasz Rekucki >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Directions on How To Help?
On 19 October 2010 23:50, OldTroll wrote: > I spotted a couple of errors in documentation and after a quick scan > on the docs website I haven't spotted a clear way to help. I can find > directions on helping with code, but I'm not certain if that applies. > Can anyone point me in the right direction? AFAIK, the same rules apply as with code. You create a ticket on http://code.djangoproject.com/simpleticket describing errors you found in a way that it will be easy to find for others. Patches are welcome, but not required. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: login_required and new class based views
On 23 October 2010 08:08, Joachim Pileborg wrote: > > On 19 Okt, 21:18, Łukasz Rekucki wrote: >> On 19 October 2010 19:06, Valentin Golev wrote:> Hello, >> > I was going to write something like LoginRequiredMixin, but I have no >> > idea how to do this. I need to run my code before .dispatch(), but I >> > also have to call the old dispatch, but since Mixin aren't inherited >> > from View, I can't just override method and use super(). >> >> This is option #4. You can just do: >> >> class LoginRequiredMixin(object): >> >> def dispatch(self, *args, **kwargs): >> bound_dispatch = super(LoginRequired, self).dispatch >> return login_required(bound_dispatch)(*args, **kwargs) This discussion has moved to django-developers. It starts in [1] and then continued in [2]. There is also a ticket #14512 for tracking this issue[3]. All help is welcome :) > > This solution looks cleanest, and is easiest to implement. However > there is > a problem if two or more similar mixins are used: The order of the > calls are > dependant on the order the view inherits the mixins. Yes it is. But I don't really see a problem with this. That's how Python works. Wrapping the mixin construction to a class decorator should make this a bit more obvious in what order the decorators will be applied. With the code above, to wrap your view "MyView" with a login_required you would need to do something like this: class MyProtectedView(LoginRequiredMixin, MyView): pass > If you make a misstake > in the inheritance-order, your mixin might not be called at all, which > might not always be whats intended. If all classes you inherit from play nicely (that means they call super() in dispatch()), they your mixin will always be called. It might be called *earlier* then you expect, but not later or not at all. > > I am personally working on option #3, with a simple linked list of > callables > that calls each other until the original "get", "post", etc. is > called. See the links. There are some problems with decorators that leave attributes (like csrf_protect) to consider. I will be more than happy to work toghether. [1]: http://groups.google.com/group/django-developers/browse_frm/thread/f4bad32127776177 [2]: http://groups.google.com/group/django-developers/browse_frm/thread/f36447f96277fe8c [3]: http://code.djangoproject.com/ticket/14512 -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: SELECT * FROM `student` WHERE mark=(select max(mark) from student)
On 26 October 2010 19:05, Steve Holden wrote: > On 10/26/2010 12:40 PM, Phlip wrote: >> Note that "isabelle_item" appears twice. We are following the auditing >> rule "always write new records to change data - never edit previous >> records". Someone edited isabelle_item's payload data (not shown), so >> we add a new record without touching the existing record. > > I hope the auditors are only forcing you to do this with records that > aren't referenced as part of relationships, otherwise your database is > going to get hammered updating all the foreign keys. > > Wouldn't it make more sense (not that auditors will necessarily be > persuaded by sensible arguments) to dump a copy of a row (plus possibly > a timestamp field) to an archival table before update? This coild easily > be done on a pre-save signal ... This sounds like what django-reversion[1] does :) [1]: http://github.com/etianen/django-reversion#readme -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Factory Squirrel
On 27 October 2010 22:17, Phlip wrote: > Djangoes: > > RoR has a fixture system called Factory Girl, which I suspect > constructs objects in native Ruby, not in JSON/YAML. > > If nobody ports it to Django I would; under the name "Factory > Squirrel". http://github.com/dnerdy/factory_boy Also, there is a more general python solution: http://farmdev.com/projects/fixture/ that supports django. You should probably check it out for inspiration before writing a one from scratch. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: newbie having trouble with conversion to south
On 28 October 2010 20:23, Sells, Fred wrote: > I’m using django 1.2.1, Python 2.4 and MySQL 5.0 and south 0.7.2 > > I’ve got an existing app, aptly named “app” which I’m am trying to convert > to south so I can make some DB changes. It seemed to install OK and I get > to here. At which point I’m lost. Could it be that Python 2.4 logging is > not compatible with south? I’m currently locked in to Python 2.4 to match > the release packaged with CentOs. That’s a management edict and there’s no > point in trying to get them to change just because it would make sense. > You should see this ticket on South's trac: http://south.aeracode.org/ticket/567; Your options are: downgrade to 0.7.1, use a version from their repository or you can just safely delete the extra args. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Use django auth system with ruby on rails
On Feb 19, 2:15 am, geraldcor wrote:
> All of your comments prompted me to start reverse engineering what
> django does and I came across the check_password method which just
> separates the algorithm, salt and hash and then sends it to the
> following method to compare the raw password to the hash password. So
> basically, in Ruby, I can do the same thing using a similar library
> and all will be good - I think. Does that sound reasonable?
It might work, but did you consider using a Single-Sign-On technique
like CAS: http://www.ja-sig.org/wiki/display/CASC/Ruby+on+Rails+CAS+Client
and http://code.google.com/p/django-cas/ ? This basicly lets you
authenticate RoR apps through CAS and your CAS server is just a simple
django app. User profiles remain independent.
>
> Greg
>
> def get_hexdigest(algorithm, salt, raw_password):
> """
> Returns a string of the hexdigest of the given plaintext password
> and salt
> using the given algorithm ('md5', 'sha1' or 'crypt').
> """
> raw_password, salt = smart_str(raw_password), smart_str(salt)
> if algorithm == 'crypt':
> try:
> import crypt
> except ImportError:
> raise ValueError('"crypt" password algorithm not supported
> in this environment')
> return crypt.crypt(raw_password, salt)
>
> if algorithm == 'md5':
> return md5_constructor(salt + raw_password).hexdigest()
> elif algorithm == 'sha1':
> return sha_constructor(salt + raw_password).hexdigest()
> raise ValueError("Got unknown password algorithm type in
> password.")
>
> On Feb 18, 8:35 am, Alex Robbins
> wrote:
>
>
>
> > You could have a secure url that the RoR apps redirect to if the user
> > isn't authenticated with Rails. That url would have the login_required
> > decorator. If they successfully login on the django side (or are
> > already logged in), then they get redirected with some sort of get
> > variable user id + hash combo. You could check the validity of the
> > user id from the hash (using a shared secret).
>
> > Alex
>
> > On Feb 17, 4:09 pm, geraldcor wrote:
>
> > > Hello all,
>
> > > Internally, we have some RoR apps and Django apps. Our main website
> > > runs on Django and is considered to be the main portal for all other
> > > apps. Currently, we have a Rails authentication system and a Django
> > > authentication system. We want to have one user table to authorize
> > > against.
>
> > > The only problem I see is that the password stored in auth_user is
> > > salted and hashed and impossible to get at because the salt is not
> > > saved. How can I use the django auth_user inRubyOn Rails?
>
> > > I have found this:http://docs.djangoproject.com/en/dev/howto/apache-auth/
> > > but I don't know if that will work on therubyserver. Both ror and
> > > django applications that we want to authenticate are on the same
> > > server and use the same db (except our main website which is on
> > > webfaction - but that's a different story I will tackle later -
> > > possibly replication?).
>
> > > So, anyone know how to a) access the raw string from auth_user or b)
> > > set upruby(or other language and extrapolate) to properly interpret
> > > the password hash?
>
> > > Thanks for listening.
>
> > > Greg
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: aggregation question
On Jun 4, 10:20 pm, "P. Kaminski" wrote:
> Hello,
> I'm studying the Django page on aggregation
> In the section 'Joins and aggregates' there's an example of how to
> create an annotation for each Store with book price ranges. But what
> if I want to do the opposite, i.e. for each available Book, look up
> through the stores and create a price range from this.
The Book model on that page has a price field. Because of that the
book price is constant across stores and your range would always be
just that number. So first you probably want to change the model to
something like this:
class Book(models.Model):
name = models.CharField(max_length=300)
class Store(models.Model):
name = models.CharField(max_length=300)
books = models.ManyToManyField(Book, through='BookPriceInStore',
related_name="stores")
class BookPriceInStore(models.Model)
store = models.ForeignKey(Store, related_name="book_prices")
book = models.ForeignKey(Book, related_name="store_prices")
price = models.DecimalField(max_digits=10, decimal_places=2)
# Then you can say:
Book.objects.annotate(max_price=Max('store_prices__price',
min_price=Min('store_prices__price'))
> This backward-looking procedure is what's I'm most interested in.
> Best regards,
> Przemek
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Aggregation of related tables
On Jun 6, 10:12 pm, Tomas Kouba wrote: > Hello all, > > I am writing an application that often lists objects and some of their > attributes in tables. > I get the list in my view and then access attributes in template. > It means that the table rendering results in many simple sql queries > (first to get the list and then > one query for every row). > Is there a way how to this in a more effective way? I can get the data > with one sql query > but it would involve some "low level" python DB access and I am curious > if this is possible > in a more "djangoish" way. Sounds like select_related() is the thing you need: http://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.QuerySet.select_related > > Thank you, > > -- > Tomas Kouba -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: 2D map application: performance and design question
On 1 November 2010 10:59, Lars Ruoff wrote:
> Hello,
>
> first of all, these are my first steps with Django, and i only have
> limited experience with Python, so please be patient.
>
> I'm using it for what is intended to be a browser game in the future.
> The main part of the game is a zoom view on a two-dimensional map of
> fields.
>
> I'm currently using Django 1.2.3 with Python 2.6 on Windows XP.
> I'm using Python-provided SQLite and Django's local debug HTTP server
> during development ('python manage.py runserver').
>
> It works pretty well, but i notice that it takes several seconds to
> update the map screen, which i consider unacceptable given the fact
> that it runs locally.
>
> I'm wondering where the performance bottleneck lies here.
> Is it...
> - SQLLite? (I.e. would switching to say PostgreSQL speed things up
> considerably?)
It could actually slow down things. Independently of the DB, you want
to set up some indexes on your models (but I don't think that's your
problem atm).
> - Djangos debug web server? (I.e. would switching to apache speed
> things up considerably?)
Bingo! The development server is single-threaded and slow, so it
totally sucks at serving *static files*. Looking at your template,
your map is composed of many images and they all have to load
sequentially via the devserver. Serving those images using Apache or
Nginx should speed up things significantly.
> - or the way my application is designed??
In the long term, when the DB really starts to be your bottleneck, you
want to do some research about all things "spatial" (like spatial
indexes).
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Why my model doesn't get saved?
On 3 November 2010 22:17, Marc Aymerich wrote: > Hi, > I have 2 abstract classes with an overrided save function, class BaseA and > class BaseB. BaseA trigger the models.Model save function, the other > doesn't. > class BaseA(models.Model): > class Meta: > abstract = True > def save(self, *args, **kwargs): > super(BaseA, self).save(*args, **kwargs) > > class BaseB(models.Model): > class Meta: > abstract = True > > def save(self, *args, **kwargs): > pass > Now I define a class that inherits from both of these classes: > class test1(BaseA, BaseB): > integer = models.IntegerField() > and when I save a test1 object it is not saved into the database. The reason > is that BaseB class doesn't call super save function. But actually I don't > see why this fact entails the object isn't saved, because models.Model > function is called through BaseA. What is the reason of this behavior? Model.save is never called. The super() in Python doesn't work like you think. It needs to be a little bit smarter to make multiple inheritance work, so the anwser is a bit complicated. Here super() looks at the runtime type of `self`, searches for class BaseA in it's Method Resolution Order (MRO) and then takes the next class in that order. So in your code class test1(BaseA, BaseB): integer = models.IntegerField() `test1` will have a MRO of [test1, BaseA, BaseB, Model, ... some irrelevant django stuff ... , object] (you can also check that with test1.__mro__). Not going into details, immediate base classes are always most important with the one on the left side being most important of them. So, the super().save() in BaseA will call the save method in BaseB which in turn will do nothing and Model.save() will never get called. For more information on MRO you can see the official documentation[1] or just google for "Python MRO". > What can I do in order to save an object into the db when I inherit from > multiple > class and one of them doesn't call the super save function? Fix the class that doesn't call super(). The class should either call super() or not provide the method at all. Otherwise it won't play well with inheritance. You can try changing BaseA.save to call Model.save instead of the super call, but then BaseA.save will never call BaseB.save if you ever decide to put any code there. Sorry, if it's not very clear. [1]: http://www.python.org/download/releases/2.3/mro/ -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: A cache-busting sledge-hammer
I would recommend using one of asset managers that provide JS/CSS
versioning instead. Their aren't very hard to install. You can compare
some of the more popular at djangopackages.com:
http://djangopackages.com/grids/g/asset-managers/
In most cases you get things like JS/CSS combining and compression as
an extra bonus. Definitly something you will want in the long run.
On 9 November 2010 13:07, Cal Leeming [Simplicity Media Ltd]
wrote:
> That's a pretty neat idea, originally I was having to use { now|date:"u" }
> to put the current epoch timestamp on the end of the urls...
>
> On 09/11/2010 10:35, Ole Laursen wrote:
>>
>> Hi!
>>
>> If you have the problem of visitors getting errors from using the old
>> Javascripts and CSS when you roll out a release, I have a sledge-
>> hammer solution that only requires a single-line change in your
>> settings.py.
>>
>> It's a middleware that examines the HTML from your views and appends a
>> little timestamp to all URLs pointing to local files it can find. No
>> further setup required, although with an extra three-line
>> configuration to lighttpd or nginx (or whatever you're using to serve
>> static files), you can achieve near-perfect caching.
>>
>> You can grab the middleware here, modtimeurls.py:
>>
>> http://people.iola.dk/olau/python/
>>
>>
>> I also blogged about the rationale behind here:
>>
>> http://ole-laursen.blogspot.com/2010/11/cache-busting-in-django.html
>>
>> Ole
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: "Include" tag and dynamically generated file to include
On 9 November 2010 11:25, samuele.mattiuzzo wrote:
> Hi all,
> i have a problem with a django template.
>
> i have a value (a number) stored into a mysql database and i'm
> accessing it using {{ totem.layout.communitySpace }}
>
> This number sould be used to get a page:
> {% include "bacheche/clip_{{ totem.layout.communitySpace }}.html" %}
>
> and it should return "clip_2.html" (for example).
>
> This doesn't seem possible, since i receive "Page
> clip_{{ totem.layout.communitySpace }}.html not found"
> I also tried without using parenthesis, but i get the same error
> ("Page clip_totem.layout.communitySpace.html not found") and i have to
> use the "ifequal" tag to include the correct page, but this isn't
> dynamic at all, everytime we add a new page, we also have to edit the
> main template if - else's statements!
>
> How can i manage this? Thank you all for your suggestions!
>
You should first create the name as a string and then pass it to the
{% include %}. You can do this in view (with a simple "clip_%d.html" %
num), a custom tag or with something horrible like this:
{% with totem.layout.communitySpace|stringformat:"d" as page_number %}
{% with "bacheche/clip_"|add:page_number|add:".html" as template_name %}
{% include template_name %}
{% endwith %}
{% endwith %}
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Error: No module named admindjango.contrib.auth
On 10 November 2010 18:39, Harry wrote:
> Trying to follow Part 2 of the Django documentation
>
>>>> python manage.py syncdb throws this when configuring admin
> 'Error: No module named admindjango.contrib.auth'
> More errors if I try to include admin docs.
>
> 1) Need to know where I can see which modules are installed
If you have "pip" you can call "pip freeze" to see all installed
python packages. This doesn't show modules inside that packages, but
it's a good overwiew of what you have.
> 2) Why this module did not install
Because a module with that name doesn't exists.
> 3) How to fix it.
Check your INSTALLED_APPS settings. It should look something like this:
INSTALLED_APPS = (
'django.contrib.admin', <--- notice the coma
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'polls'
)
If you forget the comma Python will join the two literal strings.
('django.contrib.admin'
'django.contrib.auth',)
Is the same for Python as:
('django.contrib.admindjango.contrib.auth',)
And that's not a valid application. At least that's my best guess
about your problem.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: How to extract answer from QuerySet
On 10 November 2010 21:55, Shawn Milochik wrote:
> The queryset returns zero or more instances of your model. So if
> there's only one result, you can just get the first item in the
> queryset by its index.
>
> For example:
>
> some_queryset = YourModel.objects.filter(**kwargs)
>
> if some_queryset.count() == 1:
> x = some_queryset[0]
> #x is now an instance of your model.
> else:
> raise ValueError("%d results -- expected one!" % (some_queryset.count(),)
This is a very bad way of checking queryset length, because count()
actually creates a new QuerySet that gets executed (again!). Instead
use len() that will first check against queryset's internal cache. In
this special case of one element you can also write:
try:
elem = YourModel.objects.get(**params)
except YourModel.DoesNotExists as e:
# element was not found - do something with it
pass
except YourModel.MultipleObjectsReturned as e:
# there was more then one object that matches given params - if
params include a (primary) key this shouldn't happen
pass
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: How to extract answer from QuerySet
On 10 November 2010 22:10, Shawn Milochik wrote:
> 2010/11/10 Łukasz Rekucki :
>> On 10 November 2010 21:55, Shawn Milochik wrote:
>>> The queryset returns zero or more instances of your model. So if
>>> there's only one result, you can just get the first item in the
>>> queryset by its index.
>>>
>>> For example:
>>>
>>> some_queryset = YourModel.objects.filter(**kwargs)
>>>
>>> if some_queryset.count() == 1:
>>> x = some_queryset[0]
>>> #x is now an instance of your model.
>>> else:
>>> raise ValueError("%d results -- expected one!" % (some_queryset.count(),)
>>
>> This is a very bad way of checking queryset length, because count()
>> actually creates a new QuerySet that gets executed (again!). Instead
>> use len() that will first check against queryset's internal cache.
>
> I agree that your way is better, but I disagree about duplicate
> execution -- doing a count() will simply run a SQL query that does a
> COUNT. It's not doing anything "again" because the original queryset
> hasn't actually been executed (lazy) until its contents are actually
> used (as in the variable assignment), and the COUNT statement is
> lightweight.
Yes, the original query is lazy. But the common case here is probably
that element exists, so most of the time you will be doing:
some_queryset.count() # ~= SELECT COUNT(*) FROM ...
some_queryset[0] # ~= SELECT mymodel.* FROM ... LIMIT 1
How those queries are performed of course depends on the params you
pass to filter(), but the COUNT() is not as light-weight as you think.
Assuming the simplest case of filtering by primary key, It's actually
pretty slow and requires to go through the whole index (or even a full
table scan), while a LIMIT 1 query usualy just fetches the first
element in the db index. This is why Django 1.2 has .exists() which
uses LIMIT 1.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Saving images in django
On 11 November 2010 03:19, andy wrote: > Django recommends saving images to the file system since this gives > better performance than storing the files in a database. However I > don't seen any documentation on how to restrict access to those files > by user. If someone knows the url to your image directory they could > possibly view all the content of that directory. If you create a > social network or a multi tenant application how will you handle this > issue? > > While writing this up I learned about preventing directory listing, is > this secure enough. how about obfuscating file or directory names. This largely depends on what your HTTP server can do, but with Apache you can use the X-Sendfile header. This works like this: 0. Install mod_xsendfile and put "XSendFile On" in your Apache config. See also [1]. 1. Instead of putting the images in a location with all the other media, put it in a protected location - one which the server can read, but not associated with any Location. 2. Create a view that will check permissions for a given file. As a response return an empty HttpResponse with "X-Sendfile" header containing the full filesystem path of the file to be server, or a 403 if the person is not permitted. 3. Apache will look at the response for X-Sendfile header and if present the file that the header points to will be server as a response instead. This way you can check permission in your Django app, while still having the speed of serving static files directly by HTTP server. A similar solution is also availble for nginx[2] and probably other webservers. [1]: https://tn123.org/mod_xsendfile/ [2]: http://wiki.nginx.org/NginxXSendfile -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Mysql Quires using raw()
On 11 November 2010 09:17, Jagdeep Singh Malhi wrote:
>
> now I also try another method to get max(id)
>
> from django.db import connection
> cursor = connection.cursor()
> cursor.execute('SELECT max(id) FROM automation_client')
> maxid = cursor.fetchone()
>
> output is :
> (2L,)
>
> but i want only 2 not any other character.
You have a 1 element tuple with a number. Ig you know anything about
Python, it shouldn't be hard to get that value from the tuple.
>
> Is any other method to get max(id) from database tables?
Starting from version 1.1 Django supports aggregation[1], so you can just write:
>>> from django.db.models import Max
>>> Client.objects.aggregate(maxid=Max('id'))
{'maxid': 2L}
And you'll get a dictionary with the value you want as a result.
[1]: http://docs.djangoproject.com/en/1.1/topics/db/aggregation/
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django 1.3 alpha 1 released
On 12 November 2010 01:16, hcarvalhoalves wrote: > What about having an official 1.3 feedback thread at django-developers > list? ;) > > I'm liking the pack of small improvements coming in this release, and > timing is very good, well done. I must say I'm less than happy with > the view classes though. Is the API on it frozen already? IMHO no, but it reached a point where the only way to make it better was to have it released to the wild and see how people use it. I'm personally interested in all and any feedback on the class based views. There's a few thing I would like to improve myself, but just didn't have the time to sit down and do the work. > > On 11 nov, 05:34, James Bennett wrote: >> The first alpha preview package for Django 1.3 is now available. >> >> * Release notes:http://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/ >> >> * Download instructions:http://www.djangoproject.com/download/ >> >> -- >> "Bureaucrat Conrad, you are technically correct -- the best kind of correct." > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django 1.3 alpha 1 released
On 12 November 2010 01:45, Ian Lewis wrote: > 2010/11/12 Łukasz Rekucki >> >> On 12 November 2010 01:16, hcarvalhoalves >> wrote: >> > What about having an official 1.3 feedback thread at django-developers >> > list? ;) >> > >> > I'm liking the pack of small improvements coming in this release, and >> > timing is very good, well done. I must say I'm less than happy with >> > the view classes though. Is the API on it frozen already? >> >> IMHO no, but it reached a point where the only way to make it better >> was to have it released to the wild and see how people use it. I'm >> personally interested in all and any feedback on the class based >> views. There's a few thing I would like to improve myself, but just >> didn't have the time to sit down and do the work. > > I'm not sure what is meant by improve and or what you would like to improve > specifically but, > it was my impression that this conversation had been played out and that the > API was pretty much decided. I agree. The base View class is pretty much set in stone for me. So in context of the class based views as a whole the API is frozen. But there are minor things in the generic views and mixins that django provides, that didn't work too well for me while experimenting. For example, the FormMixin assumes that only arguments to your form is "data" and "files". It's not uncommon for forms to require a request object or some other additional objects (or maybe my way of using forms is fundametally broken). To make a CreateView work with such a form, you need to needlessly reimplement the whole get_form() method. I think this should be easier. I don't want to propose any kind of revolution, but rather extend the API based on real use cases. And the reason I didn't post any proposals to change some things is that I don't feel very strong with my arguments and I don't want to waste people's time on things I'm not sure about myself. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django 1.3 alpha 1 released
On 12 November 2010 03:12, Russell Keith-Magee wrote:
> 2010/11/12 Łukasz Rekucki :
>> On 12 November 2010 01:45, Ian Lewis wrote:
>>> 2010/11/12 Łukasz Rekucki
>>>>
>>>> On 12 November 2010 01:16, hcarvalhoalves
>>>> wrote:
>>>> > What about having an official 1.3 feedback thread at django-developers
>>>> > list? ;)
>>>> >
>>>> > I'm liking the pack of small improvements coming in this release, and
>>>> > timing is very good, well done. I must say I'm less than happy with
>>>> > the view classes though. Is the API on it frozen already?
>>>>
>>>> IMHO no, but it reached a point where the only way to make it better
>>>> was to have it released to the wild and see how people use it. I'm
>>>> personally interested in all and any feedback on the class based
>>>> views. There's a few thing I would like to improve myself, but just
>>>> didn't have the time to sit down and do the work.
>>>
>>> I'm not sure what is meant by improve and or what you would like to improve
>>> specifically but,
>>> it was my impression that this conversation had been played out and that the
>>> API was pretty much decided.
>>
>> I agree. The base View class is pretty much set in stone for me. So in
>> context of the class based views as a whole the API is frozen. But
>> there are minor things in the generic views and mixins that django
>> provides, that didn't work too well for me while experimenting.
>>
>> For example, the FormMixin assumes that only arguments to your form is
>> "data" and "files". It's not uncommon for forms to require a request
>> object or some other additional objects (or maybe my way of using
>> forms is fundametally broken). To make a CreateView work with such a
>> form, you need to needlessly reimplement the whole get_form() method.
>> I think this should be easier.
>
> If I understand your use case, something like:
>
> class MyFormMixin(object):
> def get_form_class(self)
> def form_factory(self, *args, **kwargs):
> return MyForm(self.request, 'frobnitz', *args, **kwargs)
> return form_factory
>
> should do the job.
It certainly will. You can even do:
from functools import partial
class RequestFormMixin(FormMixin):
def get_form_class(self):
return partial(super(RequestFormMixin, self).get_form_class(),
self.request)
but I don't feel very comfortable with returning a function from
something named "get_form_class". This could be either renamed to
"get_form_factory" and documented as such, which means you most likely
lose the ability to dynamicaly sublass the form or add
get_form_params() method and use it in the default implementation:
class FormMixin(object):
def get_form_params(self):
data = {'initial': self.get_initial()}
if self.request.method in ('POST', 'PUT'):
data.update({'data': self.request.POST, 'files':
self.request.FILES})
return data
def get_form(self):
return self.get_form_class(**self.get_form_params())
And we probably can discuss which is better for an unlimited period of
time. So I'll just shut up and see if it's only a problem of my
personal taste or a valid point. Really, I'm very happy with CBVs and
I appreciate all the hard work of everyone that worked on this.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: I have an idea for a new tag
On 19 November 2010 19:53, Adam Hallett wrote:
> Just a thought, what about:
>
> {% for k,v in mydict|order:'key' %}
>
> or
>
> {% for k,v in mydict orderby key %}
Here's a quick hack that works right now:
{% for k, v in mydict.items|dictsort:"0" %}
{{ k }}: {{ v }}
{% endfor %}
> On Nov 19, 10:55 am, Paweł Roman wrote:
>> When rendering dictionary, there is absolutely no way to display
>> values sorted by keys. The only workaround is to copy all the dict
>> items to a sortable structure e.g. list and pass the list to the
>> template, instead of the dictionary.
Keep in mind that sorting a built-in dictionary in Python will always
require some copying, because it's a hashtable. If you need a sorted
dictionary, you must write a new datastructure like in this recipe[1]
>>
>> Why not introduce a new tag to solve this problem:
>>
>> I say, it should be called {%secretfor%} and the usage would be
>>
>> {%secretfor k,v in mydict %}
>> ... do stuff
>> {%endsecretfor%}
>>
>> would work like sorted(mydict.keys)
>>
>> I won't stick with the tag name, but you see my point.
The name is *really* awkward - what does sorting have to do with "secret"?
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: A Model to store links to other models
On 20 November 2010 02:51, Micah Carrick wrote:
> I'm having trouble coming up with a pretty solution to a seemingly simple
> task. I'm relatively new to Django.
>
> I want to allow the end user to control various lists of links on the site
> used for navigation. The admin should allow the creation of "link groups"
> which have a collection of "links". These links would reference a
> pre-determined list of models. Let's say, for example, that there is a "link
> group" created for the footer links of a website. In the admin section, a
> user could add a link to a specific blog (from the Blog model), another link
> to the about us page (flatpages), etc.
>
> In other words, I'm trying to associate individual records from a number of
> tables together as a group of objects having a URL. I'm trying to find a
> nice, abstract solution. Obviously I don't want actual URLs in the database.
> This is something I would use frequently so I want to see if I can find or
> write an app to do this--if I can come up with an elegant solution.
>
> This would be nice, but, I can't imagine how it could be possible:
>
>
> class LinkGroup(models.Model):
> site = models.ForeignKey(Site)
> name = models.CharField()
>
> class Links(models.Model):
> link_group = ForeignKey(LinkGroup)
> model_type = ???
> model_id = ForeignKey() # no can
> do!
> sort_order = PositiveIntegerField(default=100)
>
>
> This is an idea, however, I don't like having to reference the import in the
> DB. It's just begging for problems.
>
>
> class LinkModel(models.Model):
> name = models.CharField() # such as "Flat Page"
> model = models.CharField() # such as "myapp.models.FlatPage"
>
> class LinkGroup(models.Model):
> site = models.ForeignKey(Site)
> name = models.CharField() # such as "Navigation Links"
>
> class Link(models.Model):
> text = CharField() # such as "About Us"
> link_group = ForeignKey(LinkGroup)
> model = ForeignKey(LinkModel)
> model_id = PositiveIntegerField() # such as the PK for the
> myapp.models.FlatPage model
> sort_order = PositiveIntegerField(default=100)
>
>
> Any suggestions?
You should checkout generic foreign keys[1]. It's a standard way of
building models that need to reference rows in more then one table. So
your models would be something like this:
from django.contrib.contenttypes.models import ContentType
from django.contrib.contenttypes import generic
class LinkGroup(models.Model):
site = models.ForeignKey(Site)
name = models.CharField() # such as "Navigation Links"
class Link(models.Model):
link_group = ForeignKey(LinkGroup)
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
linked_object = generic.GenericForeignKey('content_type', 'object_id')
[1]:
http://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/#generic-relations
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Pydoc and security
On 20 November 2010 23:31, Robert S wrote: > Hi > I'm trying generate documentation for a django project. > > The obvious tool is pydoc, which does work. The trouble is, pydoc > publishes everything ... including passwords. Why would you put any passwords in docstrings ? -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: restrict downloading files based on user-permission
I'm guessing that your original problem was that HTTP headers can only
contain ASCII characters. To have a UTF-8 encoded name, you should use
percent-encoding. I'm using this code on production site:
quoted_name = urllib.quote(file.name.encode('utf-8'))
response['Content-Disposition'] = 'attachment; filename=%s' % quoted_name
and it works perfectly with any unicode name.
> On 21 Nov., 16:31, patrickk wrote:
>> I need to serve media-files uploaded by users, but only the user who
>> uploaded a file should be able to download that file again. therefore,
>> I need to check whether the currently logged-in user is the creator of
>> that file (ok, that´s easy with using a view).
>>
>> – of course, serving the media-file via django is not an option.
>> – downloading the file (changing the response-header) is not an option
>> either since we need to use utf-8 filenames (same goes for xsendfile).
>>
>> any ideas on how to achieve this? btw, we´re using mod_wsgi.
>>
>> thanks,
>> patrick
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: 'is None' in {% if %}
On 25 November 2010 03:48, Christophe Pettus wrote:
> I have a Decimal field that's blank=True, null=True, and NULL and 0.0 are
> distinct values. I'd like to do something different in a template depending
> on whether or not the value is None or not, but a standard {% if field %}
> treats 0.0 and None the same. Right now, I'm checking is None in the
> application and setting a separate value in the context, but is there a way
> of doing this directly on the field itself?
In Django 1.2, {% if value == None %} seems to work fine.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django feeds sometimes generate AttributeError: 'LatestStripsByStripConfig' object has no attribute '__name __'
Well, something must have changed if you didn't had the problem
before. What version of Django are you running ?
On 25 November 2010 15:38, marty3d wrote:
> Hi!
>
> My site have started to behave a little weird.
>
> Lately, I get two or three errors per day, saying:
> Traceback (most recent call last):
>
> File "/home/mistalaba/.virtualenvs/production/lib/python2.5/site-
> packages/django/core/handlers/base.py", line 95, in get_response
> response = middleware_method(request, callback, callback_args,
> callback_kwargs)
>
> File "/home/mistalaba/.virtualenvs/production/lib/python2.5/site-
> packages/django/middleware/doc.py", line 18, in process_view
> response['X-View'] = "%s.%s" % (view_func.__module__,
> view_func.__name__)
>
> AttributeError: 'LatestStripsByStripConfig' object has no attribute
> '__name__'
>
> I don't know why this is appearing all of a sudden, I haven't changed
> the code, but I don't know where to start debugging this.
>
> Here is my feeds.py, rather straightforward:
> from django.contrib.syndication.views import Feed
> from django.shortcuts import get_object_or_404
>
> from strip.models import StripConfig, Strip
>
> class LatestStripsByStripConfig(Feed):
> #__name__ = 'LatestStripsByStripConfig'
> description_template = 'feeds/latest_description.html'
>
> def get_object(self, request, stripconfig):
> return get_object_or_404(StripConfig, slug=stripconfig)
>
> def title(self, obj):
> return "Scandinavian Comics RSS feed for %s" % obj.strip_name
>
> def link(self, obj):
> return "%s?utm_source=feed&utm_medium=%s" %
> (obj.get_absolute_url(), obj.strip_name)
>
> def description(self, obj):
> return "The latest %s comic strips. See more at
> http://www.scandinavian-comics.com/strips/"; % obj.strip_name
>
> def items(self, obj):
> return
> Strip.objects.filter(strip_config__slug=obj.slug).order_by('-date')[:
> 10]
>
> def item_link(self, item):
> return "%s?utm_source=feed&utm_medium=%s&utm_campaign=%s" %
> (item.get_absolute_url(), item.strip_config, item)
>
>
> Does anyone have some wise suggestions? I would really appreciate it!
> Thank you!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Django feeds sometimes generate AttributeError: 'LatestStripsByStripConfig' object has no attribute '__name __'
On 26 November 2010 10:35, marty3d wrote: > I have disabled cache and still getting the error. That > leaves...what? :/ > > I could really appreciate some help debugging this. On a closer look, this looks like: http://code.djangoproject.com/ticket/13842 ; But then, you must have changed something in your code/settings (like migrating from Django 1.1 syndication views or adding XView). -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: newbie: concept question
On 26 November 2010 21:09, Charlietuna wrote: > Hi all, > > I looked for FAQ, but I couldn't find any. Here's my question. I've > been working through the tutorials. I've taken a community college > class on Python. So, I have some background there. > I've gotten Django installed and working. So far, I've used sqlite3. > > Here's the question: If you have an MySql database that is already > establised with data, etc, > how do you get Django to set up the abstraction of the db, so that you > can access the data. > > I've worked with the tutorials where you use Django to create the > database. You use syncdb command to setup the "abstraction" of the > data. How do you do it the other direction? If you have an existing schema in your database, you can use django-admin.py inspectdb[1] to create models from it. It's not guaranteed to be 100% correct, so you may need to tweak the generated models. If you have a database table that you want to access, but don't won't Django to manage it's schema, you can use "managed=False"[2] on the model. Hope that helps :) [1]: http://docs.djangoproject.com/en/dev/ref/django-admin/#inspectdb [2]: http://docs.djangoproject.com/en/dev/ref/models/options/#managed -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: TemplateSyntaxError with block trans
On 27 November 2010 14:12, Vyrphan wrote:
> Hi there mates,
>
> I've created a new site, and all is running ok. Last step in my
> development plan was to add support for internacionalization (by now,
> only 2 languages)
>
> I just added blocktrans in my templates in several places, and i'm
> getting allways the same exception
>
> Invalid block tag: 'blocktrans', expected 'endblock' or 'endblock
> title'
> 1 {% extends 'public.html' %}
> 2
> 3 {% block title %}
> 4 {% blocktrans %}Page title {% endblocktrans %}
> 5 {% endblock %}
>
> ...
>
> Python and django versions:
>> python --version
> Python 2.6.5
>> django-admin.py --version
> 1.2.3
>
> Any clue about what's happening?
http://docs.djangoproject.com/en/dev/topics/i18n/internationalization/#specifying-translation-strings-in-template-code
"To give your template access to these tags, put {% load i18n %}
toward the top of your template."
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Named URLs and class-based generic views
On 3 December 2010 22:40, Andrew Willey wrote:
> So it works as
>
>> url(r'^location/$', WouldLoveToHaveClassBasedView.as_view(),
>> name='name_for_convenience')
>
> Didn't realize I could just pass the class object. Makes sense.
> Guess I'm getting old and change fearing.
To be clear here - you're not passing the class object here -
as_view() returns a normal function that takes care of everything:
creating a View instance and passing request and URL params to it's
dispatch method. Class-based views get no special handling in Django,
so you could just copy the 'django.views.generic' package to your
Django<1.3 project and use them (I did :).
>
> I think the only thing that's bugging me is that you have to include
> the whole views.py in your url conf. Just feels less graceful than
> having the dispatcher nab what it needs on demand. I'll get over it.
You should avoid doing "from ... import *" and just explicitly name
the views you need. It's easier to see which views are actually used
this way. If you really want to use the string syntax:
# views.py
my_view = MyView.as_view()
# urls.py
urlpatterns('myapp.views',
url(r'some_pattern/', 'my_view', name="myapp-my_view")
)
There is not way to use a string like 'myapp.views.MyView' - you need
the alias. Also, you most likely want to name all your URL patterns
that use class-based views or you won't have a way to use reverse()
with them.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Class based views list view logic
This example should help you:
http://docs.djangoproject.com/en/dev/topics/class-based-views/#dynamic-filtering
``self.args`` and ``self.kwargs`` contain the groups matched in the
URL, so I guess you want to use ``self.args[0]`` as your Menu name.
One thing I don't understand is, why you sometimes write "Food" and
sometimes "MenuItem". Is that the same model ?
On 4 December 2010 16:34, Recep KIRMIZI wrote:
> Hi i m trying to use class based views on my project.
> I've read the documentation but i couldnt determine it well.
> what i'm trying to do is just use simple list of items of selected menu.
> i have 2 classes on my model. Menu and MenuItem. Menu corresponds of
> food menu types of a cafe; like "wine menu" "beef menu" ... and MenuItem
> is sub item of menus. like in "Wıne menu": "red wine" or "white wine" or
> some other kind of wine. but i couldnt get the list of items in the
> menu.here is my models views urls and template.
>
>
> models:
>
> #!/usr/bin/env python
> #-*- coding: utf-8 -*-
>
> from django.db import models
> from photologue.models import Photo
>
> class Menu(models.Model):
> """Model that contains the menu information\
> such as wine menu, meat menu, vegetables menu"""
>
> name = models.CharField(max_length=100, blank=True)
> slug = models.SlugField(max_length=100)
> description = models.CharField(max_length=200, blank=True)
>
> def __unicode__(self):
> return u'%s' %self.name
>
> class Food(models.Model):
> """Model that contains the foods such as white wine,\
> red wine, grilled meat, cooked meat."""
>
> name = models.CharField(max_length=100)
> menu = models.ForeignKey(Menu)
> price = models.FloatField()
> photo = models.ForeignKey(Photo)
>
> def __unicode__(self)
> return u'%s' %self.name
>
>
> urls:
>
>
> (r'^menu/(\w+)/$', FoodsListView.as_view()),
>
>
> views:
>
> #!/usr/bin/env python
> #-*- coding: utf-8 -*-
>
> from menus.models import MenuItem, Menu
> from django.shortcuts import render_to_response, get_object_or_404
> from django.views.generic import ListView
>
> class FoodsListView(ListView):
> context_object_name = "foods"
> template_name = "menu.html"
> model = Food
>
> def get_queryset(self):
> self.menu = Food.objects.filter(menu__iexact=)
> return MenuItem.objects.filter(menu=self.menu)
>
>
>
> template:
>
> % extends "base.html" %}
> {% block title %}Menu name{% endblock title %}
> {% block extra_head %}
>
> {% endblock extra_head %}
> {% block content %}
> {% for food in foods %}
> {{food}}
> {% endfor %}
> {% endblock %}
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Distinguish between None and False/0/[] in a template?
On 6 December 2010 20:31, Christophe Pettus wrote:
> Pardon if this is a FAQ, but is there a built-in way of distinguishing
> between None and the other typical false values (False/0/[]) in a template?
> Something along the lines of:
>
> {% if var == None %} ... {% endif %}
>
It's best to just try before asking if something works :) There is a
filter variant too:
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#default-if-none
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Migrating to class-based views and django.core.urlresolvers.reverse
Moved from django-developers: On 7 December 2010 20:15, Sean Brant wrote: > Again this topic is now in django-user land. > > I do this in views.py if want the decorator on all methods (get|post). > > myview = login_required(MyView.as_view()) > > > > On Dec 7, 2010, at 1:10 PM, Daniel Swarbrick > wrote: > >> That is indeed in the docs, and I have seen that. What eludes me is >> how to use decorators more complex than login_required() from within >> urls.py. >> >> For example, this works fine: >> >> from django.contrib.auth.decorators import user_passes_test >> from django.utils.decorators import method_decorator >> from django.views.generic import TemplateView, View >> >> class IndexView(TemplateView): >> template_name = 'index.html' >> >> �...@method_decorator(user_passes_test(lambda u: u.is_superuser)) >> def dispatch(self, *args, **kwargs): >> return super(IndexView, self).dispatch(*args, **kwargs) >> >> But how would one avoid having to override the dispatch() method on >> many classes, and put the user_passes_test() decorator in the urls.py >> definition? Or for that matter, the permission_required() decorator? One option is to make a base class that has the right method decorated and then subclass it. This is what the docs show. Another is to decorate the function returned by as_view(). >> >> As a side note, could a mixin be used to setup permission_required, >> login_required etc, and user-defined class-based views be derived from >> multiple parent classes? Yes. Some decorators make sense as Mixins, others don't - it's a matter of judgement. IMHO, login_required doesn't make much sense as a Mixin. >> >> Sorry if this has meandered into django-users land... maybe some >> advanced CBV examples in the docs? Here's a view from my project: @view_decorator(never_cache) @view_decorator(csrf_exempt) @view_decorator(domain_required(login=True)) class FileCollectionView(JSONMixin, PersonMixin, SingleObjectMixin, View): # lots of secret code :) pass This uses view_decorator() function I wrote[1], which is a shortcut for overriding ``as_view`` method (I prefer to override that instead of ``dispatch``). Maybe you'll find it helpful. [1]: https://github.com/lqc/django/blob/0eb2de3c156d8e6d1c31f46e0734af0ff06f93c4/django/utils/decorators.py#L46 -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django template tags.
2010/12/8 Nuño Iglesias :
>
> What i'm trying to do is this:
> {{ mystring | upper }}
> to convert "mystring" into upper-case.
AFAIR, there should be no spaces before or after "|": {{ variable|upper }}
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Generic Views - do you use them?
You should try the new class-based generic views: http://docs.djangoproject.com/en/dev/topics/class-based-views/ They're much more flexible. On 10 December 2010 02:44, Rainy wrote: > On Nov 8, 6:42 pm, Ted wrote: >> What are their pros and cons? How often do you use them when you're >> coding? >> >> The more I code in django the less I find generic views to be useful >> shortcuts (direct to template being the exception). >> >> My biggest complaints are: >> * You don't end up saving many keystrokes unless you have 3 or more >> views that are going to use the same info_dict. >> * They can't be tweaked or changed much before you have to move the >> code to the views file, destroying the keystroke savings. >> * Second syntax for doing the same thing makes Django harder to >> learn. >> >> Am I alone on this? >> >> I've thought about it and i think there is a better way. I want to >> see if there are others in the community who aren't in love with >> generic views before I develop the alternate approach. >> >> I'm not trying to start a flame war. > > They may be useful sometimes but I've never needed them > as I usually work on open-ended projects that would grow > out of generic views soon even if they may be possible to > use at first. > > I think there's a problem with the way generic views are > introduced in documentation. I've actually tutored someone > on use of Django and we ran into a problem that they > started using generic views and kept asking me how to > do this or that with them and they could do almost nothing > they wanted. I could see it was frustrating for the student. > > I think the docs should either completely move generic > views into some optional section or there should be an > extremely clear and explicit walkthrough of their limits > and a disclaimer that you shouldn't use them unless > you're pretty sure they can do everything you need your > app to do. > > I think I've seen a web talk by Adrian where he said > generic views were introduced for designers (i.e. > non-programmers) to make it possible to make a > useful app with no programming at all. I don't have > a problem with that at all. The main issue is how the docs > approach generic views.. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Generic Views - do you use them?
On 10 December 2010 22:47, Ted Tieken wrote: > Class based generic views still have the major drawbacks of the > previous version. They are a more powerful, more complicated version, > but they're still a red-herring. Can you elaborate on this ? Taking your original concerns: > My biggest complaints are: > * You don't end up saving many keystrokes unless you have 3 or more > views that are going to use the same info_dict. That sounds like a general rule for all things "generic" - if you don't have similar problems, you must have different solutions. If you have a couple of views that are almost similar, you can create a common base class and make final tweaks as parameters to the as_view() function. * They can't be tweaked or changed much before you have to move the code to the views file, destroying the keystroke savings. Class-based views are designed to solve exactly this problem. By creating a subclass you can customize the parts you want and reuse others. If the current API doesn't suite your needs, please do say. I'm not going to argue it's perfect, but it surely is the right direction :) * Second syntax for doing the same thing makes Django harder to learn. I don't understand this one. Is this targeted at old generic views or the new views ? > On Fri, Dec 10, 2010 at 9:37 AM, Rainy wrote: >> >> Is there a doc somewhere that details what the limitations are? How >> do you tell if some task is definitely too much for new generic views? >> I'm not using 1.3 yet and generally what I've been doing recently >> doesn't seem to fit generic views but eventually I might use them. What kind of limitations you have in mind ? Generic views usually can't solve your task out-of-the-box - this is where the need for customization comes from. Old generic views let you only customize small parts of variables. Class-based views take a different approach - every time there is a (substantial) decision to make, call a method on self. This way subclasses can redefine the way that decision is made without the need to copy all of the view's code. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: more than one querys LIKE in the same field
On 14 December 2010 09:10, marcoarreguin wrote:
> Hi friends!
>
> I mean do something like this:
>
> SELECT * FROM table WHERE tags LIKE '%candy%' AND tags LIKE '%milk%'
>
>
> I've tried:
>
> table.objects.filter(tags__icontains='candy', tags__icontains='milk')
>
> I've tried too:
>
> list = ['candy', 'milk']
> table.objects.filter(tags__icontains=list
>
> And nothing work. Help me please :s
It's usually more helpful to post errors you receive, so people
reading your message don't have to reproduce them on their own:
>>> print Table.objects.filter(tags__icontains="candy",
>>> tags__icontains="milk").query
File "", line 1
SyntaxError: keyword argument repeated
Ok, so we can't repeat keyword arguments in Python. Thankfully, this
isn't the only way to pass query conditions to filter[1]:
>>> print Table.objects.filter(Q(tags__icontains="candy") &
>>> Q(tags__icontains="milk")).query
SELECT "simple_table"."id", "simple_table"."tags" FROM "simple_table"
WHERE ("simple_table"."tags" LIKE %candy% ESCAPE '\'
AND "simple_table"."tags" LIKE %milk% ESCAPE '\' )
[1]:
http://docs.djangoproject.com/en/dev/topics/db/queries/#complex-lookups-with-q-objects
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Multiple conditions on same field in JOIN over three models
On 17 December 2010 19:20, Jonas H. wrote:
> Hello!
>
> Assuming the following data model:
>
> +--+ +--+ +-+
> | Blog | has many (1:n) | Post | tagged with (n:m) | Tag |
> +--+ +--+ +-+
>
> I want to filter out all blogs that have a post tagged with "foo" and "bar"
> (the same post satisfying *both* conditions).
>
> How would that query look like? Intuitively I'd say
>
> Blog.objects.filter(post__tags__name="foo",
> post__tags__name="bar")
>
> but obviously that's a SyntaxError because of the repeated keyword argument
> to filter(). I also tried Q() objects but that generates some totally
> unrelated queries.
In [9]: print Blog.objects.filter(Q(post__tags__name="foo") &
Q(post__tags__name="bar")).query
SELECT "simple_blog"."id"
FROM "simple_blog"
INNER JOIN "simple_post" ON ("simple_blog"."id" =
"simple_post"."blog_id")
INNER JOIN "simple_post_tags" ON ("simple_post"."id" =
"simple_post_tags"."post_id")
INNER JOIN "simple_tag" ON ("simple_post_tags"."tag_id" =
"simple_tag"."id")
WHERE ("simple_tag"."name" = foo AND "simple_tag"."name" = bar )
Looks related. It's exactly what you specified, but conditions you
gave are just impossible to satisfy.
Your task is a bit more complicated to do in SQL:
Blog.objects.filter(post_tags__name__in=["foo",
"bar"]).annotate(match_count=Count('post__tags')).filter(match_count=2)
This should give you the right results.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Authenticate every def in views.py
On 18 December 2010 03:43, suckerfish wrote: > Hi guys > > I've added a decorator to *each* def in views.py to require > authentication. Is there a simpler way that allows me to apply > authentication automatically to every def in the file? Depends on your code editor ? -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: registering app level signal handlers
Not every app needs/has urls.py to be included. "models.py" is imported Django's get_app(). So, something like admin.autodiscover() will also import your models. The problem with putting signal handlers in __init__, is that it isn't the place you would really expect Model related code to live (like post_save). It can also lead to non-obvious cyclic imports, 'cause your handler code will most likely need some models, etc. On 18 December 2010 06:38, Yaniv Aknin wrote: > Maybe I'm missing something here, but why not the app's __init__.py? > (my main urls.py imports all my apps' urls.py, which means their __init__.py > is likely to be called rather early in any request, no?) > > - Yaniv > > On Sat, Dec 18, 2010 at 3:10 AM, dmitry b wrote: >> >> Aren't an app's models loaded lazily (upon the first use)? >> >> On Dec 16, 7:16 pm, "W. Craig Trader" wrote: >> > I usually register the signals for a given application at the bottom of >> > that >> > app's model.py file. >> > >> > - Craig - >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Authenticate every def in views.py
On 18 December 2010 12:24, Jonas H. wrote:
> On 12/18/2010 10:30 AM, Łukasz Rekucki wrote:
>>
>> On 18 December 2010 03:43, suckerfish wrote:
>>>
>>> Hi guys
>>>
>>> I've added a decorator to *each* def in views.py to require
>>> authentication. Is there a simpler way that allows me to apply
>>> authentication automatically to every def in the file?
>>
>> Depends on your code editor ?
>
> That's not very DRY, is it :-) Try class-based views (Django 1.3/trunk).
Class-based views won't help much here. Were do you put the
"login_required" decorator. You can make a common base class or a
mixin, but then you have to remember to inherit from that - pretty
much the same amount of work as using a decorator.
>
> If you can't/don't want to use Django 1.3, you could do some automagic
> "decorating" at the end of the file:
>
> for view in ['view1, 'view2', ...]:
> eval('{0} = your_decorator({0})'.format(view)')
>
You can always do some "automagic", but as the project grows it and
you introduce more magical decorators, you really start to understand
why "explicit is better the implicit". So I wouldn't recommend that.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Authenticate every def in views.py
On 18 December 2010 13:48, James Bennett wrote: > On Fri, Dec 17, 2010 at 8:43 PM, suckerfish wrote: >> I've added a decorator to *each* def in views.py to require >> authentication. Is there a simpler way that allows me to apply >> authentication automatically to every def in the file? > > 1. Write a middleware which will force authentication on all your > views (easy), or You just have to remember to exclude the login view somehow. This is troublesome if you want to use a 3rd party app for authentication. Using decorator like @login_not_required will make you fork it. Second options is to hardcode excluded views in the middleware. I had this problem too and decided to bite the bullet for the sake of simplicity. > > 2. If you absolutely must have this happen at the view level, stick > some code in the views file which loops over the views defined in the > file and applies the auth decorator to each one. > Now that's some "automagic" :). IMHO, putting a single line in front of a view isn't THAT bad and gives important information to the person reading the code. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: turning a Model instance into an instance of one of it's subclasses
This looks a lot like this bug: http://code.djangoproject.com/ticket/7623. On 20 December 2010 23:14, morgan wahl wrote: > Yes, I had hope that would work, but it doesn't (see my original post). In > your example u.doctype would end up as None instead of 'whatever'. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: turning a Model instance into an instance of one of it's subclasses
On 21 December 2010 00:18, Morgan Wahl wrote: > Actually, it's funny you mention #7623; my situation _is_ described in > #11618 ( http://code.djangoproject.com/ticket/11618 ). That bug was > marked as a dup of #7623, but in my opinion isn't. It is a duplicate, that's why I mentioned #7623 which is tracking this bug. Existence of another table is irrelevant here, IMHO. The main scheme is the same: You have an instance of class A and you want to create an instance of class B which is a subclass of A, by writing: a = A.object.get(pk=1) # existing instance of A b = B(parent=A) b.save() # this will fail The patch on #7623 is describing exactly this situation, so you should check it out. > > 2010/12/20 Łukasz Rekucki : >> This looks a lot like this bug: http://code.djangoproject.com/ticket/7623. >> >> On 20 December 2010 23:14, morgan wahl wrote: >>> Yes, I had hope that would work, but it doesn't (see my original post). In >>> your example u.doctype would end up as None instead of 'whatever'. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Django users" group. >>> To post to this group, send email to django-us...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-users+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/django-users?hl=en. >>> >> >> >> >> -- >> Łukasz Rekucki >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To post to this group, send email to django-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Forms Questions
On 22 December 2010 22:27, hank23 wrote: > I've been going through a lot of the forms related documentation and > some things are still not clear, partly because of information > overload. > First do I have to code/generate my forms using my models? No, forms can be used independently of models. > If not then if I code my form from scratch will it still have all or > most of the background functionality as it would if I had generated it > driectly from the models? Yes, they just won't be auto-generated from your models. > Like will I still be able to use field validators, Yes. Most form fields have some validators defined (like EmailField) and you can add more: http://docs.djangoproject.com/en/dev/ref/forms/validation/#using-validators and be able to use some of the methods like is_valid(), > clean(), is_bound, as_p(), as_ul(), as_table(), etc.? Everything except save(), 'cause there is nothing to save. > I would > appreciate any help, explanations, or links to good examples or > tutorials of using forms, other than the introductory django tutorial. > Thanks in advance for the help. You can take a look at djangobook: http://www.djangobook.com/en/2.0/chapter07/ -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Splitting the models.py file
On 29 December 2010 10:37, Emmanuel Mayssat wrote: > I attempted to split the model file into a 'module' (subdir with __init__.py). > But for some reason syncdb doesn't see my app anymore. Every python file is a "module". A directory with __init__ is a "package". Now you can google for "django models package": http://www.acooke.org/cute/UsingaDire0.html -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Contact form doesn't see user as logged in
On 4 January 2011 02:27, Catalyst wrote:
> I am having trouble with a contact form on my site. Whenever I hit
> the page, it doesn't see that the user is logged in. Here's how my
> code looks.
How do you check that user is logged in ? If it's via request.user,
then it doesn't work 'cause you
aren't passing the request object to your template's context. The
recomended way to do this is using RequestContext:
from django.template import RequestContext
return render_to_response('forms/contact.html', {'form': form},
context_instance=RequestContext(request))
>
>
> #forms.py
>
> from django import forms
> from django.utils.translation import ungettext, ugettext_lazy as _
>
> class ContactForm(forms.Form):
> subject = forms.CharField()
> email = forms.EmailField(required=False)
> message =
> forms.CharField(widget=forms.Textarea(attrs={'rows':'20',
> 'cols':'75'}))
>
>
>
>
> #urls.py
> from django.conf.urls.defaults import *
>
> urlpatterns = patterns('myproject.forms.views',
> (r'^contact-us/$', 'contact'),
> )
>
>
>
>
> #views.py
>
> from django.core.mail import send_mail
> from django.http import HttpResponseRedirect
> from django.shortcuts import render_to_response
> from myproject.forms.forms import ContactForm
>
> def contact(request):
> if request.method == 'POST':
> form = ContactForm(request.POST)
> if form.is_valid():
> cd = form.cleaned_data
> send_mail(
> cd['subject'],
> cd['message']+'\nUser email '+cd['email'],
> ('formemailaddr...@email.com'),
> ['sendaddr...@email.com'],
> )
> return HttpResponseRedirect('/forms/thanks/')
> else:
> form = ContactForm()
> return render_to_response('forms/contact.html', {'form': form})
>
>
>
> If I hit another page, the user still shows up as being logged in,
> just this one area (the contact form) doesn't. Even the thank you page
> shows the user as being logged in.
>
> Anyone have any ideas?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Class based views and form processing
``CreateView`` includes ``ModelFormMixin``, which is responsible for saving the model form: def form_valid(self, form): self.object = form.save() return super(ModelFormMixin, self).form_valid(form) So, you need to override that method in your subclass: class ListCreateView(CreateView): model = List form_class = ListForm def form_valid(self, form): self.object = form.save(commit=False) self.object.created_by = request.user self.object.save() # Ok, so now you have a problem. Calling super will call form.save() again. # A dirty hack is to skip ModelFormMixin in MRO - *note* - it's a dirty hack return super(ModelFormMixin, self).form_valid(form) Looks like it's an oversight in the API, unless someone can come up with a cleaner solution. On 10 January 2011 01:53, Justin wrote: > Hello, > > I am experimenting with the new class based views coming in 1.3 and am > having trouble figuring out when/where to put this code. I want to > populate a model's created_by field with the user of the current > request. > > In the old views, I would have done something this: > obj = form.save(commit=False) > obj.created_by = request.user > obj.save() > > Now I am using a generic CreateView class: > class ListCreateView(CreateView): > model = List > form_class = ListForm > > I tried supplying an initial data dictionary by overriding > get_initial(), but this doesn't work because the `created_by` field > has editable=False so the form doesn't include it in the fields list. > > Am I missing something simple? Probably :). Any help would be greatly > appreciated! > > Thanks, > -Justin > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: upload files via ajax
On 11 January 2011 11:28, Jani Tiainen wrote: > On Monday 10 January 2011 16:05:13 Mauro wrote: >> On 23 Dic 2010, 23:12, Paul Osman wrote: >> > On Thu, Dec 23, 2010 at 9:39 AM, Mauro wrote: >> > > Hello, >> > > is it possible to upload files via ajax? >> > > >> > > I would like to upload multiple files in my application but i have the >> > > following exception: >> > > >> > > MultiPartParserError: Invalid boundary in multipart: None >> > > >> > > I'm using django 1.1. >> > > The ajax request has the content type header set as mulitpart/form- >> > > data >> > >> > This was recently posted to the Mozilla Webdev blog. Might help you: >> > >> > http://blog.mozilla.com/webdev/2010/09/17/django-and-ajax-image-uploads/ >> > >> > -Paul >> >> Hi, thanks for replying, but would like to choose the files at once >> and then upload them one by one (without flash, only html). Using an >> ajax request, django returns the MultiParseError. Moreover i try to >> user request._post_raw_data, but i would like to send also some other >> informations together with the files, and i do not to retrieve them >> from raw_data, >> Any other idea? > > First at all this is not possible. It is not possible send files using ajax. Yes you can: http://www.w3.org/TR/XMLHttpRequest2/ This only works fully in Firefox 4 and Webkit browsers (last I tested). Firefox 3.6 lacks the FormData object, but has an API to read files from JavaScript, so you can form-encode the data yourself and use xhr.send(). An almost complete implementation can be seen here: http://code.google.com/p/jquery-html5-upload/. > > But you can use ajaxy like approach. Common way is to create (invisible) > iframe where you clone original form and just do normal post there. > > When iframe loads you can post back response from server to your application. > It's not fully ajax but as close as it can get without using flash. I call this HTML4 fallback. I have a whole jQuery plugin that transparently uses an IFrame if the user's browser doesn't have any of required HTML5 capabilities. It lets you upload multiply files with additional POST data (e.g. file description, tags). Sadly, I can't open-source it just yet. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Help optimising database calls
On 12 January 2011 16:32, Matt Henderson wrote:
> Hello,
> I'm new to django, and set up a website recently, (puncut.com). I was hoping
> someone might be able to explain how to optimise database calls because at
> the moment some pages are taking 5 seconds before django responds.
> I'll summarise the scenario below:
> # models
> class Thread(models.Model) :
> ... bunch of fields including title, description, author (linked to User)
>
> class Pun(models.Model) :
> thread = models.ForeignKey(Thread)
> author = models.ForeignKey(User)
> ... other fields like content etc.
> class Like(models.Model) :
> liker = models.ForeignKey(User)
> pun = models.ForeignKey(Pun)
> So there are puns in threads, and users can like puns.
> The view which lists latest threads is particularly slow. It sends threads
> to the template, and the template loops through threads and inside it loops
> through the puns which are in that thread. in pseudo code:
> for thread in threads
> for pun in thread.pun_set
> output pun.content
> But I reckon that makes way to many calls to the database. I think I ought
> to use select_related , but I tried it and it didn't speed it up.
> Thanks for any help,
> Matt
select_related() won't help you as it only traverses relations
"forward" ( you could select all puns with their thread, but not the
other way). AFAIK, this limitation comes from SQL, not the ORM itself.
The solution is to make the join/group_by operation "by-hand":
theads = list(Thread.objects.all()) # Materialize the queryset
threads_map = {}
for t in threads:
threads_map[t.pk] = t
t.pun_collection = []
for pun in Puns.objects.all(): # or if threads are limited:
filter(thread__in=threads)
t[pun.thread_id].pun_collection.append(pun)
# now ``threads`` contains a list of threads with assigned puns.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: template tag arithmetic
On 18 January 2011 15:46, Konrad Delong wrote:
> On 18 January 2011 15:02, Thomas wrote:
>>
>> Am 18.01.2011 um 14:53 schrieb GD:
>>
>>>
>>> Hi everyone,
>>> Is there a way to do simple loop counter manipulation within the
>>> template? I.e something along the lines of:
>>>
>>> {% for x in a %}
>>> loop number = {{forloop.counter +1}}
>>> {% endfor %}
>>>
>>> with the intention of
>>>
>>> 2
>>> 3
>>> 4
>>>
>>>
>>> as output. I realise the above doesn't work, but is there any scope
>>> for this sort of thing within the templating language itself?
>>>
>
>
> You can write a filter:
>
> http://docs.djangoproject.com/en/1.2/howto/custom-template-tags/#writing-custom-template-filters
>
>>> {% for x in a %}
>>> loop number = {{forloop.counter|increase}}
>>> {% endfor %}
>
> cheers,
> Konrad
>
Actually, that case is already covered by builtin filter "add":
{% for x in a %} {{ forloop_counter|add:"1" }} {% endfor %}
:)
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Error 'long' has no attribute provision
On 19 January 2011 18:06, John wrote:
> def reports_list(request, period_id)
> # some other irrelevant code
> try:
> reportheader=ReportHeader.objects.get(pk=1
> except Exception, e:
> pass
> return render_to_response("reports_list.html, locals(),
> context_instance=RequestContext(request))
1) You don't want to modify __init__() of your model like this:
def __init__(self, request, *args, **kwargs)
self.provision=request.provision
self.period=self.provision.get_current_period()
If the new constructor requires an additional "request", how does the
ORM create instances of it ? It doesn't know anything about request.
You can make a helper function. Or if you really want to be a part of
the class, make an alternative constructor:
@classmethod
def from_provision(cls, provision):
instance = cls()
instance.provision = provision
instance.perio = provision.get_current_period()
# in your view code::
header = ReportHeader.from_provision(requrest.provision)
2) The moment you wrote "locals()" all the code in your view becomes
relevant, because you're passing all the local variables to your
template. This seems very popular amongst some groups, but I
personally consider this not only bad style, but error-prone and
possibly dangerous.
3) Catching exceptions like that most likely masks the real problem
(Like the fact, that creating an instance of ReportHeader failed, due
to buggy constructor). After all, you're rendering the template even
if you failed to fetch the data you most likely need to render it.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: [django-users] Custom signals
On 20 January 2011 02:00, Piotr Zalewa wrote: > I'm trying to add custom signals to my models. > I'm sure I'm missing some step. > > http://paste.pocoo.org/show/323618/ > The "sender" argument in receiver() must match the one in send() (using identity). In receive() you're using a class, while in send() you're passing an instance of that class, so they have no chance of matching. Try: post_copy.send(sender=type(self), copied_to=new_version) -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Questions - Django -- Bash problem
On 23 January 2011 11:54, Kimberly wrote: > Hello, I have another question. When it comes to Django, I notice some > people type as django-admin startproject project and some have to type > as django-admin.py startproject project ( in my case, I had to do > that), is it base on the setup of the Django that cause the > differences between the admin.py and admin? Django provides the script as "django-admin.py"; Some Linux distributions (like Ubuntu) package Django with the script renamed to "django-admin". So that's the cause of the difference and it's not something that Django has any influence on. > > Also, on the command line, I typed " manage.py startapp tolls" after > being side my project directory and now it says bash: manage.py: > command not found Yes, because that's how bash works. If the script is not on PATH, then bash won't find it. If you want to run a script from current directory: ./manage.py startapp tolls Note, that the file has to be executable, for this to work (it's not by default). That's why Django's tutorial suggests writing: python manage.py startapp tolls To avoid the need of explaining about bash, permission, etc. > > I've checked the directory I am using and the manage.py file is there. > I also set the _init_.py to where the operating system - os is > imported and that the django_setting_module is set to settings. Any > advices will be greatly appreciated. Thanks! > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: parsing SOAP request
Hey, On 27 January 2011 07:32, sami nathan wrote: > Hi > i am working web service i am getting SOAP(POST) request from client now > i am trying to parse the request xml and sending the response my soap > request is > > encoding=\'UTF-8\'?> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> eiveShortMessageRequest > xmlns:ns1="http://flypp.infy.com/sms/v2010r1_0";> D>12345343661t1 ctionID>p1p2 ge>DICT > test Envelope>']}> > response > now i want send response as change is denoted in colors > ' xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> eiveShortMessageRequest > xmlns:ns1="http://flypp.infy.com/sms/v2010r1_0";> D>12345343661t1 ctionID>p1p2 ge>TEXT > HERE Envelope>']}> > Ok, so what problem are you encountering and what have you already tried ? -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: ANN: Server upgrade on djangoproject.com
On 28 January 2011 21:33, Jacob Kaplan-Moss wrote: > Hi folks -- > > I'm starting the switchover to the new djangoproject.com server right > now. Might be around 5 mins of downtime or so. > > Jacob > Hurray for upgrading the Trac instance! Are there any additional Trac features planned ? (like the Vote Plugin). -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: loading the external css file
On 31 January 2011 12:17, Ben Dembroski wrote: > Hi all, > > I was having the same trouble (using version 1.2). I double checked > that I was looking at the correct documentation: > > http://docs.djangoproject.com/en/1.2/howto/static-files/ Django 1.2 doesn't have (never did and won't have) the static-files. The on-line docs are currently a bit broken after the recent switchover of djangoproject.com to the new server. All of 1.2 docs that are online, are actually 1.3 docs with wrong header. Either use 1.1 docs, or build yourself a localversion (this has extra advantage of being available even if your internet fails) until the problem is fixed. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: matching a domain name in urls.py
> On Thu, Feb 3, 2011 at 4:50 PM, mike171562 wrote:
>> I think i got it now with
>>
>> (r'^zones/(?P[.\w]+)/$', get_domain)
Depending on what you plan to do with the matched string later, you
may want to limit it to 256 characters or incorporate some more
checks, like:
r"^zones/(?P(?:[A-Za-z-]{1,63}\.){0,4}(?:[A-Za-z-]{1,63}))"
On 3 February 2011 17:52, Tom Evans wrote:
>
> . matches any character, not just dot. Your class '[.\w]+' will
> actually match anything and everything. I think you want '[\.\w]'.
>
Not if used in a character class:
>>> re.match("[.]", ".")
<_sre.SRE_Match object at 0xb72fe330>
>>> re.match("[.]", "1")
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Charfield, limiting acceptable characters
On 4 February 2011 20:47, ozgur yilmaz wrote:
> It was possible in the past with validator_list. Like:
>
> regex = r'^[A-z][\w-]{2,31}$'
>
> name = models.CharField(max_length=32, unique=True ,
> validator_list=[validators.MatchesRegularExpression(regex)] )
>
It still is? http://docs.djangoproject.com/en/dev/ref/models/fields/#validators
+ http://docs.djangoproject.com/en/1.2/ref/validators/#regexvalidator
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Looking for IDE + FTP
On 9 February 2011 02:03, Karen McNeil wrote: > So... that's a no, then? > > I mean, about the question I asked. You know, the "is there an IDE + > FTP program" question? Quoting http://www.aptana.org/products/studio2: File Transfer & Synchronization Support for one-shot as well as keep-synchronized setups. Multiple protocols including FTP, SFTP and FTPS. Ability to automatically publish your application to selected ISPs and hosting services. > - I *do* do a very simple kind of version control, where I save a > numbered copy of the major site files > whenever I've made changes and I've got a stable, working site. > I've looked into Subversion and Git and, > believe me, they would be way overkill for my little projects. Version control is never an overkill, if the setup is so simple (like in Git or Mercurial - that git init doesn't really cost you anything). Plus it solves 3 major problems: 1) Keeping history for your own sanity. Too many times I seen people go crazy over code that "suddenly stoped working even if I revert the change". 2) Backups - pushing your code to remote sites like Bitbucket or Github is a great way, to make sure you don't lose or your work. 3) Deployment - Instead of uploading stuff via FTP, you can just push your changes to the site. This wil proably require some more knowledge about VCS, but it will save lots of time. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django 1.3 class based generic views queryset
On 9 February 2011 19:16, Phil M wrote: > class SampleModelManager(models.Manager): > def published(self): > return self.get_query_set().filter(published=True, > date__lte=datetime.datetime.now()) > This is the source of your problem. Later, you have: class SampleModelDetailView(DetailView): queryset = SampleModel.objects.published() But this code is a class definition, so it will run only once on application startup. DetailView is carefuly using clone(), to avoid cache'ing issues, but it doesn't have a way to figure out, that it should change one of the filtering params. See this paragraph[1] in the docs. Your view should like something like this: class PublishedDetailView(DetailView): queryset = SampleModel.objects.all() def get_queryset(self) return super(PublishedDetailView, self).get_queryset().filter(published=True, date__lte=datetime.datetime.now()) # or at least the datetime.now() part mustbe dynamic http://docs.djangoproject.com/en/dev/topics/class-based-views/#dynamic-filtering -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Class-based views & authentication
On 16 February 2011 19:46, Andre Terra wrote: > I should also add that the functionality described in the docs simply did > not work for me: > http://docs.djangoproject.com/en/dev//topics/class-based-views/#decorating-the-class > > My attempt to follow that approach is registered here: > http://dpaste.com/hold/423359/ It's an error in the docs. It should be: class ProtectedView(TemplateView): template_name = 'secret.html' @method_decorator(login_required) def dispatch(self, *args, **kwargs): return super(ProtectedView, self).dispatch(*args, **kwargs) You can report it to the bug tracker here: http://code.djangoproject.com/newticket Thanks. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: db_index=True doesn't create index
On 1 March 2011 20:48, Dario Bertini wrote: > > but i've found no related bug on the bug tracker (except for a not- > very-related and also old and fixed one: > http://code.djangoproject.com/ticket/1828 > ) See http://code.djangoproject.com/ticket/14651 Also, from PostgreSQL's docs: One should, however, be aware that there's no need to manually create indexes on unique columns; doing so would just duplicate the automatically-created index. So there is just no need, to create the index - it's already there. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: deprecation warning
On 6 March 2011 13:55, Gabriel - Iulian Dumbrava wrote: > I couldn't find any reference on what I have to change to get rid of > this deprecation warning. I'm using the trunk version: > > VERSION = (1, 3, 0, 'beta', 1) > > This is what I get: > > [Sun Mar 06 14:47:36 2011] [error] /usr/local/lib/python2.6/dist- > packages/django/db/models/fields/subclassing.py:80: > DeprecationWarning: A Field class whose get_db_prep_value method > hasn't been updated to take `connection` and `prepared` arguments. > [Sun Mar 06 14:47:36 2011] [error] new_class = super(SubfieldBase, > cls).__new__(cls, name, bases, attrs) > http://docs.djangoproject.com/en/dev/releases/1.2/#get-db-prep-methods-on-field All deprecated things start with PendingDeprecationWarning (which is silent by default), so if you're seeing a DeprecationWarning it's most likely something deprecated in previous version. (Unless you're using Python 2.7 or later, which also silences DeprecationWarning, so you should run your code with "-Wd" to see them). -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django & Two Factor Authentication (2FA)
On 24 March 2011 14:50, pokecho wrote: > Hi Sam, > > > So how do I configure contrib.auth to authenticate against three input > values "username"(static), password(static/encrypted) and PIN/ > token(dynamic/encrypted)? That is the question. As Sam already said, you need to write a custom authentication backend[1] and use it instead of the default one. Of course, you'll also need a custom form on your login page. If you want to use the same system in Django's admin, you'll need to create your own subclass of AdminSite and override the form and template used[2]. [1]: http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend [2]: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.AdminSite.login_form -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: decorators and generic views
On 24 March 2011 15:32, Ian Stokes-Rees wrote:
> I think with the move to class-based Generic Views it is necessary to update
> this documentation:
>
> Limiting access to generic views
>
> To limit access to a generic view, write a thin wrapper around the view, and
> point your URLconf to your wrapper instead of the generic view itself. For
> example:
>
> from django.views.generic.date_based import object_detail
>
> @login_required
> def limited_object_detail(*args, **kwargs):
> return object_detail(*args, **kwargs)
Yeah, that probably needs an update. The topic guide on Class-based
Generic views has the right examples[1]:
### In URLconf, you can do:
from django.contrib.auth.decorators import login_required
from django.views.generic import TemplateView
urlpatterns = patterns('',
(r'^about/',login_required(TemplateView.as_view(template_name="secret.html"))),
)
### Decorating class:
from django.contrib.auth.decorators import login_required
from django.utils.decorators import method_decorator
from django.views.generic import TemplateView
class ProtectedView(TemplateView):
template_name = 'secret.html'
@method_decorator(login_required)
def dispatch(self, *args, **kwargs):
return super(ProtectedView, self).dispatch(*args, **kwargs)
---
You can also decorate as_view(), like you tried to:
from django.contrib.auth.decorators import login_required
from django.utils.decorators import classonlymethod
from django.views.generic import TemplateView
class ProtectedView(TemplateView):
@classonlymethod
def as_view(cls, **initargs):
return login_required(super(ProtectedView, cls).as_view(**initargs))
This can be further abstracted into view_decorator() function[2].
[1]:
http://docs.djangoproject.com/en/dev/topics/class-based-views/#decorating-the-class
[2]:
https://github.com/lqc/django/blob/0eb2de3c156d8e6d1c31f46e0734af0ff06f93c4/django/utils/decorators.py#L46
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Failed to build documentation (solved)
On 24 March 2011 20:15, Lic. José M. Rodriguez Bacallao wrote: > so, no one? > > On Thu, Mar 24, 2011 at 11:42 AM, Lic. José M. Rodriguez Bacallao > wrote: >> hey, I am using ubuntu 10.10, do I really need to update Sphinx to >> build documentation? >> Yes, you do. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: url - hot to set properly?
On 27 March 2011 14:51, Pascal Germroth wrote:
> Hi,
>
>> urlpatterns = patterns('',
>> url(r'^admin/', include(admin.site.urls)),
>> (r'^', include('apps.textcontent.urls')),
>> )
>
>> when i pass: /admin/ all is ok, but when I pass /admin -
>> apps.textcontent.urls are executed, but why?
>
> Well because the URL pattern is a regular expression that is matched against
> the URL, and you explicitly stated that there has to be a / at the end.
>
> Change it to url(r'^admin/?',…) and it will work both with '/admin' and
> '/admin/'.
>
> But: this is bad URL etiquette. You should choose a schema (/ or not) and
> stick with it. Even better: create a view that matches the opposite of your
> chosen schema and permanently redirects to the correct URL (or enable
> normalisation in your webserver, that would be easier)
Good news, Django already provides a way to do this. See
APPEND_SLASH[1] setting and CommonMiddleware[2].
[1]: http://docs.djangoproject.com/en/1.3/ref/settings/#append-slash
[2]:
http://docs.djangoproject.com/en/1.3/ref/middleware/#django.middleware.common.CommonMiddleware
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: about url tag
On 31 March 2011 17:16, Lic. José M. Rodriguez Bacallao
wrote:
> use the tag:
> url
What do you mean by that ? Do you mean the {% url %} template tag, or
the `url` function commonly used in urls.py module. Give us some
examples of what you want to achieve and what problems you have.
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: about url tag
On 31 March 2011 18:50, Lic. José M. Rodriguez Bacallao wrote: > well, I don't know if this is ok, but I solved the problem adding a > name='help_subject' tu the urlconf line Sorry, I couldn't answer earlier, but yes - that is exactly what you should do. Class-based views can't be referenced by using dot notation, so you must name them and reverse them by name. Django expects a string in form of ".". A class-based view is not a module, so it has no chance of success. Even if it somehow was able to get the as_view method from the class, there is no way to tell to which URL it was bound (look at how as_view() works for more details). Naming all your URLs is a good practice anyway. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: New python, django user... having issues
On 16 April 2011 16:36, Walt wrote: > Windows 64 does make things interesting, but just to summarize > what I do to install on Windows: > > Install mod_python for python 2.5: Do yourself a favour and switch to something else then mod_python. It's a dead project (that's why it probably won't work with newer Python). Use mod_wsgi, uwsgi or gunicorn (or any other WSGI server). > The reason for using 2.5 is that mod_python or windows and > the MySQL Python connector only support that version, at > least as far as I have been able to find. The PyPI page says otherwise[1]. You probably mean that there is no binary packages for newer Python versions. If you trust random blogs, here are some packages [2][3]. [1]: http://pypi.python.org/pypi/MySQL-python/1.2.3 [2]: http://www.codegood.com/archives/4 [3]: http://www.codegood.com/archives/129 -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Error was: No module named io
It's not a path problem. It's a python version problem: http://docs.python.org/library/io.html "New in version 2.6." It's not a problem with Django as 1.3 runs fine on 2.5.X. It's a problem in your code, so either upgrade to 2.6 or rewrite your code in terms of the older API that io module replaces. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Error was: No module named io
On 29 August 2011 15:26, CrabbyPete wrote: > This is what I suspected. Even though Django 1.3 is supposed to > support python 2.5 > Don't want to be rude, but let me repeat: "It's not a problem with Django as 1.3 runs fine on 2.5.X. It's a problem in **your code**". If you're trying to use a non-existant module, there's not much Django can do about it. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: request.user not pickable anymore
On 16 September 2011 22:05, Torsten Bronger wrote: > this means that we don't have to do anything. Not really. To 1.4 not be affected, someone needs to write a patch for that ticket. This can be you ;) -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
