Re: auto urls for methods
On Thu, Aug 21, 2008 at 4:51 AM, Will Rocisky <[EMAIL PROTECTED]> wrote: > Is it possible (like Rails) to not to enter every method and it's url > everytime? And url should go to the method straight unless defined. No. 1. Python's general philosophy is that it's best to explicitly say what you want, rather than have magical implicit things happening behind the scenes (and generally explicit is much easier to debug). 2. Auto-routing URLs takes away your ability to control what you expose of your application. This can create situations ranging from annoying URLs that you'd rather not have people see, all the way up to full-blown oh-hai-i-haxed-ur-site security holes. 3. Auto-routing only works if you're following an extremely narrow interpretation of web development patterns, namely "strict" MVC with a controller_name/view_name/object_id layout, and there are problems both with that narrow interpretation and with the conventions it foists upon you (which this margin is too short to contain). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Reverse URL Questions
On Thu, Aug 21, 2008 at 1:50 AM, Rodney Topor <[EMAIL PROTECTED]> wrote:
> So: Why is the use of explicit URLs discouraged, especially in
> templates? Why is it better to write {% url
> project_name.app_name.views.results %} in a template than to write /
> results/ (assuming the URLconf maps /results/ to the view results)?
So say you write a blog application. It has an Entry model, and its
get_absolute_url() method looks like this:
def get_absolute_url(self):
return "/weblog/%s/%s/" % (self.pub_date.strftime("%Y/%b/%d"), self.slug)
All is well and good.
Then you need to roll out the same app, on the same server, but for a
different site. And that site doesn't want its weblog entries living
at "/weblog/"; it wants, maybe, "/articles/".
Oops.
Oh, and it turns out that's going to conflict with your news
application, which is already trying to use "/articles/" in its
get_absolute_url(). The news stories are going to have to move to
"/stories/". And instead of having photographs at "/pics/", this site
needs to have them at "/photos/".
And the list goes on.
So you can go mess around with ABSOLUTE_URL_OVERRIDES to try to make
this all work, which is a bit of a nasty hack and requires you to be
constantly duplicating information: not only do you have to lay out
the URL patterns in urls.py, you also have to go hard-code the *same*
sets of URLs in ABSOLUTE_URL_OVERRIDES.
This gets very ugly, very quickly. Trust me, because I've been in that
exact situation and I know from experience that it does not end well.
Or you can just write the get_absolute_url() method to use reverse
resolution so that the only thing you have to do is write the URL
patterns you'd be writing anyway, and the reverse resolution will make
sure get_absolute_url() returns the right URL.
> Second: Doesn't the use of get_absolute_url() somehow violate the
> separation of URLs from models?
Nope. In object-oriented programming an object is *supposed* to know
things about itself. You're supposed to be able to take an object and
ask it questions like "who created you?" and "when were you last
updated?" and, yes, even "where can I see you on the public web site?"
Setting up your code so that questions about a model object can be
answered using nothing more than that model object's own API
drastically improves the cleanliness of your code; you've got one
place to go for these questions, instead of fifteen.
> Third: If one is to reverse map views to URLs, which is the best way
> to do it (if there is a best way)?
Clarify what you mean by this?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: how to display date nicely
2008/8/18 Will Rocisky <[EMAIL PROTECTED]>: > actually I have to do it in views, not template > I need some pure python code All Python datetime objects support the 'strftime' method, which is what you want to use. Consult Python's documentation for the full details. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Making a Form from a model using ModelForms, but dont want to include the ForeignKey variable in the form
On Mon, Jul 21, 2008 at 4:09 PM, Django_newbie <[EMAIL PROTECTED]> wrote: > This save() fails because the form.is_valid() is not true, and the > Blog(foreignkey) field is missing from the post data, how can i make > this save without letting user choose this blog field? Or is it > necessary that the foreignkey field has to be alwayz chosen from a > form? The documentation for ModelForm covers both: 1. Excluding fields from a ModelForm (thus doing away with attempts to validate those fields), and 2. Getting a "partial" object back from a ModelForm which you can modify before actually saving to your database. Details are available here: http://www.djangoproject.com/documentation/modelforms/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: autodiscover() fails too silently...
On Mon, Jul 21, 2008 at 4:12 PM, Amit Ramon <[EMAIL PROTECTED]> wrote: > autodiscover() goes over INSTALLED_APPS and tries to import their admin > modules. When such a module isn't present, ImportError is caught and > consumed. However, if some admin module do exists, but for some reason it > throws an ImportError (e.g., it tries to load a non-existing module), it will > not be loaded and will not be seen in the admin interface, without any > significant notice. To me this seems like an undesired side-effect, perhaps > even a bug. This is a well-known side effect of anything which needs to import something which might not exist: it is nearly impossible to write robust code that can correctly differentiate: 1. An ImportError raised by a non-existent module 2. A module which exists but whose initialization raises an ImportError The solution is to test your code independently and ensure that it functions correctly before attempting to use it (e.g., write a unit test which attempts to import your admin declarations and fails if an exception is raised in the process; if this test passes, you can rest easy). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Is Django development active?
On Sun, Jul 20, 2008 at 6:57 AM, Hussein B <[EMAIL PROTECTED]> wrote: > I got that illusion due the slow official releases cycle... Be careful with this logic, because it is misleading. For example: Britain has not had a new Prime Minister since June 2007; does this mean the British Government has not done anything in the past year? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django vs. Kohana
On Wed, Jul 16, 2008 at 6:05 PM, Henrik Bechmann <[EMAIL PROTECTED]> wrote: > Can anyone with experience or knowledge of both Django and Kohana (PHP > framework, son of CodeIgniter) list contexts in which each would be > most appropriate? I'm in a selection process right now with both on > the short list. Both are most appropriate in the context of building a web application. In all honesty, this is something that a random bunch of strangers probably can't help you much with; only you know your actual requirements and only you know your preferences for tools and coding styles, so only you can make this decision. Django's feature set is well-documented, and hopefully other frameworks do the same, so reading through the available documentation and doing a tutorial or two is probably your best bet. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Where is the source code for Practical Django Projects?
On Thu, Jul 17, 2008 at 2:14 AM, Phillip Parrin <[EMAIL PROTECTED]> wrote: > I'm also looking for the souce code, mainly i'm looking for the > advanced templates you mention when building the weblog. Did you get > the chance to finish the source? I'm tracking down one other reported issue which -- hopefully -- will be fixed for me soon by the merge of newforms-admin, but which is holding me up a bit as I try to wrap up the tarball. In the meantime, all the relevant code is right there in the book ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Where is the source code for Practical Django Projects?
On Wed, Jul 9, 2008 at 3:33 AM, Evan H. Carmi <[EMAIL PROTECTED]> wrote: > I am reading Practical Django Projects but am unable to find the online > source code. Does anyone know where this is located? I would think that > it would be at http://www.apress.com/book/view/1590599969. However, that > doesn't seem to be the case. Long story made short: The source package was all ready to go when someone who had an early copy of the book ran into a problem with a third-party application, used in a couple of the projects in the book, that had a backwards-incompatible change after we went through tech review. Rather than have people downloading broken code, I went back to work trying to fix things up and provide some notes on the problem and how to work around it. Except I also have a day job which takes up quite a lot of my time. I'd planned to finish everything up over the weekend, but unfortunately I was wiped out by an illness and I'm just not starting to get back to the land of the usefully-living. So it's not online yet and probably won't be for a couple days yet, until I've had time to get caught up on other work and triple-check everything. In the meantime, all the code that's actually vital to working through the book is right there in the book; the downloadable package is simply a copy of what's in the book, plus a couple extra examples that aren't directly covered and don't really include any fundamentally-important stuff. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: not allowing me to login to admin site
On Tue, Jul 8, 2008 at 4:33 AM, allisongardner
<[EMAIL PROTECTED]> wrote:
> Will look further into problem as it does not accept any of my user
> logins that have been created by the admin site, even though I know i
> am using the correct username and password. I do have shell access as
> I am using my own computer. When I have worked out what to do I will
> look into your second suggestion. Thanks agin for quick response.
> MWAH!!!
If you're on Django 0.96 or a checkout of the development code,
there's special-case handling in the admin for creating users such
that the password will be properly set, as well as a special-case
editing view for changing passwords through the admin.
For manually creating users from Python code, the Django User model
has a manager with a special method -- create_user() -- which will
handle this for you, so doing:
from django.contrib.auth.models import User
u = User.objects.create_user('bob', '[EMAIL PROTECTED]', 'some_password')
will work.
For manually editing users from Python code, the User model defines a
method called 'set_password()' which also handles this for you:
from django.contrib.auth.models import User
u = User.objects.get(username='bob')
u.set_password('some_new_password')
u.save()
For bulk imports, you can currently rely on some backwards-compatible
hackery we do to support storing passwords as plain old MD5 hashes, by
which Django will transparently "upgrade" the stored password to a
(more secure) salted SHA1 hash the next time the user successfully
logs in.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Create field from two others
On Thu, Jul 3, 2008 at 8:59 PM, lukeqsee <[EMAIL PROTECTED]> wrote: > > Can you take a first_name & a last_name field and then in the same > model make a field that is full_name? ie > first_name = models.CharField(max_length=75) > last_name = models.CharField(max_length=75) > full_name = models.CharField(value=first_name + last_name, > max_length=100) Not like this, no, but you seem to be hung up on trying to use field classes for everything. This is not necessary (and in this case would be a bad idea: you'd have duplicated data and you'd need to constantly watch out to prevent the fields getting out of sync with each other), because you can define perfectly normal Python attributes and methods on your models. Most likely you want to use a property with both a getter and a setter, as shown in the examples in the documentation: http://www.djangoproject.com/documentation/models/properties/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Using SQLite in production
On Thu, Jul 3, 2008 at 8:28 PM, Alex Slesarev <[EMAIL PROTECTED]> wrote: > One more issue - if you change a model, then you have to drop database > and recreate it using syncdb (sqlite do not allow modifying tables and > columns). It is not so good for production use. This is not quite correct. SQLite has limited support for ALTER TABLE statements, which is a different thing from saying it has no support for them. It is possible, in SQLite, to rename tables and to add new columns directly through ALTER TABLE statements. It is not possible to do more -- directly. However, it *is* possible to alter a schema without dropping the entire table: 1. Create a new table, with a temporary name, and with the correct definition to match the new schema. 2. Copy data into that table from the original table, inserting it appropriately to suit the new schema. 3. Drop the original table. 4. Rename the new table to the original table's name. Yes, this is more complex. However, it is often less complex than completely re-creating things from scratch. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django+mod_python, caching or something else?
On Wed, Jul 2, 2008 at 7:09 AM, Alex Koshelev <[EMAIL PROTECTED]> wrote:
> Client-side caching. Use the `never_cache` decorator
No, that's not it at all.
> On Jul 2, 3:43 pm, Mario <[EMAIL PROTECTED]> wrote:
>> I look at sql log - django didn't query that, but always query lists,
>> for example:
>> context["news_list"] = News.objects.filter(hot=False).order_by('-
>> created')[:5]
>>
>> what is this? mod_python? caching?
When launched, mod_python loads your code once and only once for each
server process, and holds it in memory afterward. This is a trade-off
made or efficiency, because reloading the code on every request would
significantly slow the server. As a result, whenever you make a change
to code that runs under mod_python, you must also restart the web
server.
In addition, any variable assigned at the module global level will
only be evaluated once, which means that any top-level variable
declaration which does a database query will only evaluate once per
server process, rather than appearing to refresh on each request.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: template via email
On Tue, Jul 1, 2008 at 8:37 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Look at the render_to_string() method for converting templates to > strings: > http://www.djangoproject.com/documentation/templates_python/#the-render-to-string-shortcut And if you end up using a template to generate the subject of the email as well (not an uncommon thing), remember that you **must** condense the subject to a single line of text. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: help request using python_twitter api with django and errno 25
On Fri, Jun 27, 2008 at 11:02 PM, Hani <[EMAIL PROTECTED]> wrote: > My questions are: > 1. can anyone explain the error a little better to me? > 2. Is it a bug in the python-twitter api, or in django, or in my code? > 3. Is there a fix that does not involve using the patch? > 4. If I have to use the patch, could someone provide easy to follow > steps for me to apply it (absolutely no clue here)? Question 1 (this is going to gloss over a lot of things, but hopefully will help): Basically, on Unix and Unix-like systems, there is a concept of a "controlling terminal" -- for example, if you're on Mac OS X (which is BSD-ish Unix under the hood), you can open a Terminal and launch a Python interpreter; in this case, the instance of Terminal.app you're using will be the "controlling terminal" of the process the Python interpreter is running in. It's often useful to get information about your controlling process, because this can answer some fairly practical question; in the case of the Twitter API, it was looking for the username of the logged-in user who launch the Python process, which is available if, for example, it was launched directly from a command line. Python's standard 'os' module allows you to do this sort of thing fairly easily. However, there are cases where the controlling process doesn't support this sort of thing, and in those cases the Python functions will raise an IOError (you can also take some steps to determine in advance whether your controlling process supports these functions). Question 2: Yes, it is (or was) a bug in the Twitter module. Question 3: the ticket you're looking at is a duplicate of one I filed earlier, and which was marked fixed some time ago: http://code.google.com/p/python-twitter/issues/detail?id=14 The relevant patch catches the IOError and falls back to a default value when the necessary information isn't available: http://code.google.com/p/python-twitter/source/detail?r=113# So if you do an svn up on your copy of the Twitter module, it should work. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Need help including a queryset in every view
On Fri, Jun 27, 2008 at 4:27 PM, Brandon Taylor <[EMAIL PROTECTED]> wrote: > What's the best way to go about this? Obviously I don't want to have > to pass the queryset into the context of every action, in every view > across the entire site :) Same way you make anything accessible to lots of different template contexts: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: psycopg2
On Fri, Jun 27, 2008 at 6:19 AM, Will <[EMAIL PROTECTED]> wrote: > Ah, sorry. Reading the Django book had led me to believe I was stuck > with psycopg: The change which allows user-defined backends to be plugged in happened after the 0.96 release, so the book is accurate for 0.96. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: psycopg2
On Fri, Jun 27, 2008 at 3:06 AM, Will <[EMAIL PROTECTED]> wrote: > Would I have to write an entire new backend for postgres, just to use > a different driver? You'd need a module that implements the interface of a Django database adapter while using another driver. A few months ago I saw an article by someone who'd been working on a module to use pygresql -- another Python module that can talk to Postgres -- in place of psycopg and who apparently got it partially working before going back to psycopg: http://www.dougblog.com/articles/2008/apr/16/exploring-a-pygresql-backend/ If you're adamantly against using psycopg (I'm not an expert on the comparison, but most Python folks seem to prefer psycopg for its flexibility in allowing customized mappings between Python data types and Postgres data types), you might get in touch with him and see if he still has/is willing to share the code as a starting point for an alternative adapter. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django naming conventions ?
On Wed, Jun 25, 2008 at 5:02 PM, PFL <[EMAIL PROTECTED]> wrote: > I have done some searching but could not find a set of standard naming > conventions that is recommended for Django objects: There's really not much that's Django-specific; as with most Python code, the recommendation is to follow the Python style guide: http://www.python.org/dev/peps/pep-0008/ -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Hooking up Users and Profiles
On Tue, Jun 24, 2008 at 2:53 PM, radioflyer <[EMAIL PROTECTED]> wrote: > I continue to struggle with what I see as some real limitations of the > User/UserProfile paradigm used by Django. Well, it doesn't cover every conceivable thing you might want to do, which is to be expected; out of the box, the most common case (single user type, single profile model) is covered, and more complex situations -- which will probably require customization anyway -- aren't. > One issue, which I have seen a number of people struggling with is the > usability of the Users selection widget. The problem is that when > creating users, there are no required fields that make for easy > ordering, searching or readability. If first_name, last_name were > required, they could be used to make the selection widget order-able > and more readable. Of course, no one wants to have Django hardwire > anything but the bare minimum fields for the authentication system so > this is understandable. So if it's important to require these fields, then write forms for entering users which require these fields. The fact that they're not required at the model level doesn't forbid you setting up requirements at a form level. > Because I want administrators of the site to have an easy way to give > Users a choice of different profiles, I've had to try some different > approaches. One other thing you might try is exploring the Group model as a way to keep users organized according to who they are -- e.g., have "Teacher" group, a "Student" group, etc., and use group membership to determine which profile model you want to use for a given user. >- All of the child user types show up in the add/change admin for > users. The administrator would have to remember what type of user they > were adding and do a lot of scrolling around irrelevant fields. You're really getting into a case where the stock admin doesn't suit your needs, and instead of stepping back and writing what would be a few short, simple views to do exactly what you want you're still trying to force what you want into a codebase that wasn't designed for this. newforms-admin might help you a little bit by giving you places to just plug in and override, but I really think writing a couple views and forms that handle your custom logic is the way to go here. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: psycopg2
On Tue, Jun 24, 2008 at 12:20 PM, Will <[EMAIL PROTECTED]> wrote: > I really didn't want to turn this into a fight, and I apologise if my > posts have seemed inflammatory. I'd just like to be able to trust all > my stack. Well, this is the thing: are you going to this level of detail on *every* part of your stack? Are you auditing the kernel and the C libraries? Are you checking the security of the firmware for the drives in your server? Or are you putting some trust into the fact that widely-used components wouldn't be so widely used, or would at least have lots of people complaining about them, if they weren't reliable? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: psycopg2
On Tue, Jun 24, 2008 at 11:28 AM, Will <[EMAIL PROTECTED]> wrote: > All I'm asking for is some reason to trust the integrity of psycopg, > and all I'm getting from you is sarcasm. Perhaps you could provide me > with some links? psycopg is used, happily, by everyone from hobbyists to Fortune 500 companies. It works just fine, and it's easy to discover this. If your clients are concerned about its quality, add three figures to the amount on your invoice and trust that they're the sort of people to whom "expensive" means "good". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Extending the method that is called the first time a model is deployed.
On Sun, Jun 22, 2008 at 4:41 AM, mwebs <[EMAIL PROTECTED]> wrote: > It seems as if these signals have to be used in management.py, but > what I need is something I can use directly in my model code. > Something like overloading a method. The fact that this should be > happen in the model-class is very important. E.g I dont want every > model to be registerd in my "meta-model" Apps only some of my models. I think you've misunderstood how signals work; you can selectively do something only when a certain specific class is first loaded. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: get_models
On Thu, Jun 19, 2008 at 9:11 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > This is just one of those areas that we haven't got around to > documenting yet. It doesn't mean we don't want to document this > feature - it just means other things have taken priority. We're always > open to contributions, though. If you want to write up some > documentation based on what you have just learned, feel free to > volunteer. Also, there were a few long-running tickets related to model loading, so at the time it didn't make sense to document an API that might have to change when those tickets were fixed. It turned out that the model-loading API could stay backwards-compatible (which was a good thing), so now if someone wants a good task for a sprint they should look into documenting it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: get_models
On Thu, Jun 19, 2008 at 8:01 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > In fact, I'm confident enough that they're not going anywhere that I'm > in the process of documenting them on dead trees. I already beat you to it, at least partially (got some uses of get_model() in my book). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: get_models
On Thu, Jun 19, 2008 at 7:02 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Short version: See also long version: http://www.b-list.org/weblog/2007/nov/03/working-models/ If these functions were to change, Django itself would need to undergo not-insignificant refactoring. And since such a refactoring is not on the table, they're not going to change. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Freelance Django Developers Urgently Needed
Hey, there, django-users subscribers! This is your periodic friendly reminder that the place for job listings is http://djangogigs.com/, which exists specifically to serve that purpose. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Use new variables on templates
On Sun, Jun 15, 2008 at 11:29 AM, Eric Abrahamsen <[EMAIL PROTECTED]> wrote: > One of the things django does for you is make 'settings' available > everywhere. So if you want to use these constants in a template, you > should be able to do this in a view: Er. No, no it doesn't. If you want access to the settings, you import them like any other Python code. And if you want something to be available in every template, you write and enable a context processor and use RequestContext. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: problem with forms with db access
On Sun, Jun 15, 2008 at 7:58 AM, ./ed <[EMAIL PROTECTED]> wrote: > the problem is that when i add an entry to the aModel table it does > not update in the form (even with various reload scheme) > it does update when I 'touch' the python file. So my guess is the > problem lies in the 'compilation' chain or something like that. Consider the following normal Python class: import datetime class BeforeAfterNoon(object): time = datetime.datetime.now() @classmethod def before_noon(cls): return cls.time.hour < 12 Now, suppose you import this class at 11:59, and call the 'before_noon()' method. It will return True. Suppose you leave the Python interpreter running and don't reload anything; at 12:01, 'before_noon()' will still return True. This is because -- when Python parsed the class definition -- the current date and time were assigned to the attribute 'time' in the class, the same as if a constant value had been assigned, and it won't change until something forces the class definition to be completely reloaded, at which point it will update to a new value and stick *there* instead. Assigning choices to a field in a form works the same way; even if the choices come from calling a function, it still happens only once -- when the class is first loaded. This deals with the general case of what you're seeing. For the specific case of dynamically pulling choices for a form field from a QuerySet, you want to take a look at the documentation: http://www.djangoproject.com/documentation/newforms/#fields-which-handle-relationships -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: simple python math help.
On Sun, Jun 15, 2008 at 4:36 AM, Jarred Bishop <[EMAIL PROTECTED]> wrote: > it returns '0'. which isnt much help. how do i get '0.5' or '.5' ? This has a very long history, going all the way back to the C programming language (which the Python interpreter is written in, and which many currently-popular languages are, at least in part, descended from). In C dividing an integer by an integer always yields an integer, no matter what -- if you care about fractional/decimal bits, you need to ensure that one or both of the numbers involved supports having fractional/decimal bits. Python has inherited this quirk, and so the following situation exists: 200 / 400 # yields 0 200.0 / 400 # yields 0.5 200 / 400.0 # yields 0.5 200.0 / 400.0 # yields 0.5 One possible solution, then, is to ensure that at least one of the numbers involved is a floating-point number (Python type 'float') instead of a whole integer (Python type 'int'). This behavior will be changing in Python 3.0, but will not be changed in the Python 2.x line because it's backwards-incompatible. In Python 3.0: 200 / 400 # yields 0.5 200 // 400 # yields 0, because there are cases where "integer division" is useful Until then, you can selectively enable this by adding the following at the top of any Python file where you're doing division: from __future__ import division This turns on the (backwards-incompatible with code which assumes Python's standard integer division) behavior which will be standard in Python 3.0. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Disconnected ORM objects
On Fri, Jun 13, 2008 at 11:01 PM, Karish <[EMAIL PROTECTED]> wrote: > I want to be able to use my ORM objects (eg, EmailMessage, > EmailAddress) in some cases without a database. For example, I want to > write a function like download_email_messages that will download email > messages and return an EmailMessage object which has a set of > EmailAddress objects (for the To, From, etc.). The database is not > involved at this stage. If an object doesn't represent something backed by a relational store, why are you using an object-relational mapper to handle it? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Extending User model with model inheritance?
On Fri, Jun 13, 2008 at 10:54 PM, meppum <[EMAIL PROTECTED]> wrote: > With the query refactoring branch being merged to the trunk I wanted > to finally move some of the data I had put on my user profiles to a > derrived user model. I didn't see this mentioned in the documentation > and I wanted to know if this is possible now? Will the admin tool pick > up new fields? The admin interface does not currently support inheritance; support is planned in newforms-admin, slated to merge to trunk within the next couple of months. In the meantime, subclassing User to add fields offers no performance advantage whatsoever over using a related model, because the subclassing is implemented under the hood as a related table with a foreign key back to the parent class. In many cases it also offers little conceptual advantage, because the great majority of things people typically do with user profiles have little or nothing to do with user authentication. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Roadmap to 1.0 and internationalization in db
On Fri, Jun 13, 2008 at 5:38 PM, Adrián Ribao <[EMAIL PROTECTED]> wrote: > I think I can make this work in three weeks, If I do, could it be > considered for Django 1.0? Since it appears that it wouldn't introduce any backwards-incompatible changes, I'd be against putting it on a 1.0 timeline; it could just as easily be added in a 1.x release afterward. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django-registration with my custom user profile
2008/6/13 Chr1s <[EMAIL PROTECTED]>: > But still I don't know how to implement this, anyone could give me a > simple example? thanks very much This feature is intended for a situation where each of the following is true: 1. You have a custom user-profile model. 2. The user-profile model has been written in such a way that an instance can be created using nothing but default values (e.g., with no input whatsoever from the user). If that is the case, simply write a function which can create an instance using nothing but default values, and pass that as the argument. If that is not the case, you will either need to write a more complex custom form (to handle any additional information you want to collect) or create the profile in a separate step (e.g., using django-profiles). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Tutorial Clarification
On Fri, Jun 13, 2008 at 2:24 AM, wave connexion(BQ) <[EMAIL PROTECTED]> wrote: > Does this mean Django generated API code for you? No. The phrase "no code generation necessary" means precisely what it says: that, unlike some frameworks which require you to run a script which generates files of code for you, Django's database API is generated dynamically at runtime. > Here, that an app can be in multiple projects means the app code can be > copied/imported into different projects rather than shared between different > projects? In the largest sense, it means that an application is simply a Python module, and thus the standard Python "import" statement can be used to access it the same as any other Python code; this means that a single application module can be re-used by multiple Django projects without needing to make multiple copies of the application module (just as any other Python library can be imported by multiple pieces of code without needing its files to be copied into new locations by each of them). > not very clear on this. more explanation is appreciated. An explanation of that code is provided in the section immediately following it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: SQLobject vs SQLAlchemy
On Fri, Jun 13, 2008 at 1:15 AM, Pepsi330ml <[EMAIL PROTECTED]> wrote: > i shall go read more about SqlObject then. If you're planning to use Django, and if you do not already have a very strong attachment to another ORM, consider just using the one that comes with Django. It will make your life easier. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Painfully slow... why?
On Tue, Jun 10, 2008 at 7:42 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > At the risk of talking to myself, I may have found the cause of my > slowdowns: KeepAlive. Setting it OFF has -- so far -- made a HUGE > performance improvement. More than I saw from memcached, or anything > I've done with the queries. That'll do it (and IIRC it's covered in the deployment docs). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: "more than 1 ForeignKey" error in newforms-admin
On Mon, Jun 9, 2008 at 2:08 PM, Andre Meyer <[EMAIL PROTECTED]> wrote: > i have a model with a class that has a foreign key and a subclass that has > another. this works well for creating the database, but the admin does not > like it. I believe your problem is that support for hierarchies of subclassed models is still in progress. Right now, using the admin on top of such models doesn't work. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Suitable for this?
On Sun, Jun 8, 2008 at 1:05 AM, beetlecube <[EMAIL PROTECTED]> wrote: > I read a blog entry somewhere by someone contemplating the ideal type > of web application needs that Django best meets: Since it was > written originally for publishing articles in a newspaper environment, > it's good for blogs or other Article type sites. My usual response to this is as follows: "I was thinking about using Rails to build my site, but it looks like it's really only good for AJAX-heavy project-management and to-do-list applications. Should I consider something else if that's not what I'm building?" And sometimes I think people underestimate just what goes into a high-quality newspaper site; there are tons of interactive and intense data-processing and other background things going on at, say, ljworld.com, but people hear "newspaper" and think "oh, it's just some basic CMS stuff". If anyone really thinks it's that easy, they're welcome to come work for us and see how things really are ;) > Shouldn't matter, should it, what kind of web app? More succinctly, no, it shouldn't. I've seen Django used, successfully, for projects all over the spectrum of web development (CMS, data processing, highly interactive user-content apps, even point-of-sale systems). Ultimately, it's up to you to make the call as to whether it's right for what you want to do, but unless you're in a domain where there's a need for highly specialized tools (for example: if I were building a live IM system in Python I'd use Twisted for its awesome network-oriented features), Django should be fine. So if it feels right for the way you like to develop, go for it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: I need outsourcing
Once again: Please route job listings to djangogigs.com. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django programming project
On Fri, Jun 6, 2008 at 7:55 PM, david.watson <[EMAIL PROTECTED]> wrote: > I have a relatively simple django project that I need to get done. > I'm an experienced software engineer, but I don't have the cycles to > do this myself. I have, however, carefully thought out the > requirements and design, so I can be quite clear about what I need > done. Please route job listings to djangogigs.com, which exists specifically for this purpose. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ORM question
On Fri, Jun 6, 2008 at 6:57 PM, Dan W. <[EMAIL PROTECTED]> wrote: > I'm pretty new to django and so far so good except for one thing. When I > fetch model objects, their related objects are showing up as RelatedManager > and ManyRelatedManager objects intead of the types I created and modified in > my model. Consequently if I try to iterate over them or access their data > attributes, I get an exception. http://www.djangoproject.com/documentation/db-api/#related-objects You want the sections on "backward" and "many-to-many" relationships. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Caching question
On Fri, Jun 6, 2008 at 2:11 PM, Peter Rowell <[EMAIL PROTECTED]> wrote: > I'm a little confused. The docs (http://www.djangoproject.com/ > documentation/middleware/#django-middleware-cache-cachemiddleware) > say, and the code appears to support it, that if > django.middleware.cache.CacheMiddleware in the MIDDLEWARE_CLASSES > list, then caching is turned on for the whole site. Yes. The question here, though, was the interaction of CacheMiddleware, the anonymous-only caching setting, and other caching mechanisms. Which is why I ran down what each one of them does in the face of the anonymous-only caching setting. > I don't see > anything in the middleware code that knows anything about the > cache_page decorator. The cache_page decorator is actually literally the same code as the middleware; there's a utility function in Django that can convert a middleware class to a decorator, and the cache_page decorator is the result of applying that utility to the CacheMiddleware. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Caching question
On Thu, Jun 5, 2008 at 3:05 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> I've read the caching documentation several times, but must be missing
> some fine points. If I have
> CACHE_MIDDLEWARE_ANONYMOUS_ONLY = True
> set, does per-view or template fragment caching override that?
If you have CacheMiddleware enabled, and you have
CACHE_MIDDLEWARE_ANONYMOUS_ONLY = True in your settings file, then:
* Assuming you don't use any other caching mechanisms of any sort,
caching only occurs for anonymous users.
* If you apply the cache_page decorator to a specific view, the
caching performed by that decorator only occurs for anonymous users.
* If you use the {% cache %} tag in a template, the caching occurs for
all users in all situations regardless of anonymous status.
* If you use the low-level cache.get()/cache.set() API, the caching
occurs for all users in all situations regardless of anonymous status.
Basically, this means that when you single out a small fragment of
template or Python code and use the fine-grained caching mechanisms,
Django assumes you've got a good reason for doing so and know better
than it does that you want to cache.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Can Someone Do something about ALL THIS SPAM
Guys, this has been covered before, multiple times. But once more, with feeling: * The list is run through Google Groups, so Google's spam filtering is what's applied. * The way to train Google's spam filter is to use their spam-reporting mechanism. * The alternative to this is to start moderating the list, which would be such an overwhelming task that it's logistically impossible, plus the Django team doesn't want to end up creating a closed list where people have to await approval to post, and so nobody bothers trying. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: why so slow?
On Tue, Jun 3, 2008 at 4:00 PM, <[EMAIL PROTECTED]> wrote: > im running part 2 of the tutorial right now and im inside the admin. > when connecting to localhost it is s slow, why? If you need to have a running dialogue with someone who can help you as you walk through the tutorial, consider joining the Django IRC channel for live chat. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django + google appengine?
On Tue, Jun 3, 2008 at 4:02 PM, <[EMAIL PROTECTED]> wrote: > google appengine seems like a good place to start, then i dont have to > get my own servers and stuff. > > is this easy integrateable? or doesnt google appengine and django work > together? There are a number of articles and tutorials which you'll find with some simple searching. In the future, please consider doing so; searching in Google for an answer to your questions will often get you help much more quickly than waiting for a mailing list to respond. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: why do i have to add this to Apache?
On Tue, Jun 3, 2008 at 2:17 PM, <[EMAIL PROTECTED]> wrote: > why is this necessary? do i have to do this for every project? > testproject.settings implies i do. You probably want to research how mod_python works in order to understand what the configuration directives are and which ones are necessary. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: auto admin for production
On Tue, Jun 3, 2008 at 11:54 AM, pihentagy <[EMAIL PROTECTED]> wrote: >> Currently the admin interface doesn't handle row-level permissions. A >> user can be granted to edit articles, but not restricted to only their >> own. I *believe* this is a feature that will be added in newforms-admin. > > Can anyone confirm that? If so, where can I find the docs? There isn't going to be any magical switch or option that you just turn on and suddenly these restrictions go into place. Instead, you'll have much more access to customize the lists of objects which are shown to individual users, by overriding methods which return the QuerySets used in the admin interface. There is no documentation at the moment because the code is still evolving. And to cut off the next few questions since I'm certain someone will ask them yet again: no, I don't know when it will merge into trunk; no, there is not an estimated date for it; no, there is not a timeline for it; yes, it will be sometime before Django 1.0. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: "Includes" directory?
On Mon, Jun 2, 2008 at 1:29 PM, Huuuze <[EMAIL PROTECTED]> wrote: > I'm new to Django, so please be gentle. Basic question: when > developing a web app, I've typically created an "includes" directory > which stores commonly used functions or methods. From a best practice > standpoint, is it recommended that I create an "includes" directory > (not application) within my project? If so, I'm guessing I can > reference it as "myproject.includes". Generally, any time you find yourself giving a module or file a name such as: * includes * parts * utils * helpers * misc it means that your code is not as well-organized as it could be. Additionally, such things tend to grow over time, until you wake up one morning and discover that 'includes.py' is 5,000 lines long and contains over half the code of your application, simply because it was easy to put things in there instead of taking the time to maintain a more careful organizational structure. Without knowing exactly what type of code you're talking about, though, it's nearly impossible to suggest alternative ways to keep things organized. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to import ModelForm Dynamically?
On Mon, Jun 2, 2008 at 9:06 AM, David.D <[EMAIL PROTECTED]> wrote:
> views.py
> ==
> def model_form(request, model_name):
>form_class = __import__('products.models.%sForm'%model_name)
>form = form_class()
>...
>
> model_name is a string
Unless you really grok how __import__() works, it's often best to
avoid it. Here's an alternative solution::
import products.models as product_models
def model_form(request, model_name):
return getattr(product_models, '%sForm' % model_name)()
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Method .cache() for QuerySet
On Mon, Jun 2, 2008 at 11:58 AM, Marinho Brandao <[EMAIL PROTECTED]> wrote: > Meanwhile, I am not sure if it is safe as I need, so, I wish to know > your opinion about it: Review of patches proposed for Django should take place in the Django ticket tracker; djangosnippets is not the appropriate place for this, and I've removed it from the site. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How nicely does django play in a distributed environment?
On Mon, Jun 2, 2008 at 7:06 AM, Phillip B Oldham <[EMAIL PROTECTED]> wrote: > I'm looking at using django to replace our current CMS application > written in PHP. Currently we have two servers behind a load balancer, > and everything's nice and stable. We're getting a consistent month-on- > month traffic increase though and I'm looking at moving to a more > distributed model - localised servers for uk/us/eu with replicated > mysql instances. Django is the easy part. Replicating your DB is the hard part. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: local import or not for django apps?
On Thu, May 29, 2008 at 4:06 PM, Milan Andric <[EMAIL PROTECTED]> wrote: > Anyone happen to have a strong opinion on this? Should django > applications use local imports or package based imports? Sorry if > this has been mulled over a million times. Applications should expect to live on the Python path (which is where they end up if you're using the standard Python packaging tools), and they should use imports which assume that they're on the Python path. So, for example, if the views file in the application 'foo' needs to access a model 'Bar' in its own models package, it should write 'from foo.models import Bar'. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django and Comma-Formatting Numbers
On Thu, May 29, 2008 at 1:15 PM, David <[EMAIL PROTECTED]> wrote: > I had need of commas in floating-point numbers, and slightly modified > humanize.py with a floatcomma function: > > def floatcomma(value): >""" >Converts a float to a string containing commas every three digits. >For example, 3000.65 becomes '3,000.65' and -45000.00 becomes > '-45,000.00'. >""" Of course, keep in mind that this has internationalization issues; there are places where the number "three thousand point six five" is written "3000,65" or even "3.000,65". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: may be BUG. SyntaxError: non-keyword arg after keyword arg
On Wed, May 28, 2008 at 4:32 AM, sector119 <[EMAIL PROTECTED]> wrote: > Is it a bug, or I misunderstood something in filter usage? It looks like you have stray whitespace or line breaks in the middle of things which should be continuous text. This would, naturally, lead to strange behavior. For example, this works: User.objects.get(username__exact='bob') But this probably won't: User.objects.get(user name __ exact='bob') Double-check your code. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: hanging os.system() when doing pdf generation
On Tue, May 27, 2008 at 11:05 AM, Milan Andric <[EMAIL PROTECTED]> wrote: > Worked just fine from the interpreter but I noticed some stuff being > returned on stdout (same as on cmd line). So I added the --quiet > option to htmldoc and now it seems fine and returns 0 in the > interpreter. Maybe the os.system() call within the view didn't make > django very happy since it was returning junk. Some WSGI-based web servers will crash and/or otherwise have severe problems if you try to write to stdout from inside a WSGI application. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to Implement "Most Viewed"?
On Sun, May 25, 2008 at 9:08 PM, jonknee <[EMAIL PROTECTED]> wrote: > Unless you cache the view. Just update it once an hour/day. You still have to record the raw number of hits somewhere. Doing this in the database, in real time, is often not possible because it does lead to one write per page view. Periodically crunching server logs is often a better alternative. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Avoiding code duplication with many similar models
On Sun, May 25, 2008 at 10:13 PM, Trevor Caira <[EMAIL PROTECTED]> wrote: > So while it is possible to do this with model inheritence, at least > the most obvious solution involves a lot of code duplication. A situation like this is often an indicator that you haven't sufficiently abstracted what the code is doing. Step back a bit and consider whether that's the case. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Authenticated user from models.py
On Wed, May 21, 2008 at 8:23 PM, Patrick J. Anderson <[EMAIL PROTECTED]> wrote: > Passing a Request object should work in application views, but what if > one wants to capture that information on every save() call, including in > the admin? > > What would be an elegant and beautiful approach to solving this problem? Well, newforms-admin is being written to make the HttpRequest object available as an argument to the various ModelAdmin methods, which means that when you set up your own custom admin you can do pretty much anything you want. Which will make a lot of people happy, and let them go right on building workflows that don't make a lot of sense (if somebody's a trusted administrator, how come you don't trust them to fill in a field properly?). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Reusable models?
On Wed, May 21, 2008 at 12:29 PM, Aidas Bendoraitis <[EMAIL PROTECTED]> wrote: > One use case could be, for example, > the Institution model with title and description fields in project A, > then the Institution model with title, description, and address fields > in project B, > and then the Institution model with title, description, and category > fields in project C. A whole bunch of people are going to tell you to use inheritance and subclass the base model everywhere. Those people are probably a bit over-eager to treat inheritance as a cure-all; the only time I've ever seen it used in production code, it became a maintenance nightmare (pro tip: World Online has been using Django since, well, as long as it's existed. We have exactly one model that's subclassed, and every time I have to deal with it I wish it wasn't). The way I'd do this is with an application which provides a basic model with the core fields, and then other models in other applications relating to it and adding information as needed. Incidentally, this leads to precisely the same underlying database configuration as inheritance, but is conceptually quite a bit cleaner since you're being explicit about the relationship. Note that this is, for example, how Django's User model works: you relate another model to it with a good old-fashioned foreign key, and there's a nice API for specifying which model represents the "user profile" for a given site. You could emulate that for your own models quite easily. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Authentication for whole app
On Tue, May 20, 2008 at 8:57 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > Let me ask my own question then. If one is running multiple Django > instances, does Django provide anything that would help with single > sign on (SSO) across all the distinct Django application instances? Well, they can share a database and auth against a single users table (we do this all the time), or you can have an external authentication source and write an auth backend which knows how to talk to it and authenticate against it, then use it on all the sites which need it. I've seen people doing LDAP and various other corporate-love-fest auth systems that way. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Authentication for whole app
On Tue, May 20, 2008 at 7:14 PM, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > If you want to use HTTP Basic authentication, then put everything > under/behind Apache and use Apache to do it. If you want to use form > based authentication with same user database across all applications > gets a bit harder. Which do you want? It's actually not that hard, even if you want to require auth only for specific areas. A middleware like this might do the trick (with a little tweaking): from django.contrib.auth.decorators import login_required class AuthRequiredMiddleware(object): def process_view(self, request, view_func, view_args, view_kwargs): if ... (fill in test here to see if it's a URL or view you want to require auth for): return login_required(view_func)(request, *view_args, **view_kwargs) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: user.is_authenticated is always false using default login
On Tue, May 20, 2008 at 10:32 AM, Andrew English <[EMAIL PROTECTED]> wrote: > Do I need to explicitly call authenticate and login in my own view to > populate the user data? From what I read, it seems that the > django.contrib.auth.views.login does that automatically. There's a difference between authenticating the user, which you've done, and making the user object available as a variable to the template, which I'm guessing you haven't done. You probably want to read this: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: "request"object within models.py
On Mon, May 19, 2008 at 4:10 PM, Tim Chase <[EMAIL PROTECTED]> wrote: > It's the last bit that can throw folks...many folks seem to use > very nice/helpful bits of the framework that abstract the save() > call so it's never thought-about. Wouldn't adding a parameter to > save() stymie the admin and a number of other places that call > save() without parameters? Well, for years now I've been telling anyone who will listen that auto-filling a foreign key in the admin like this is generally a bad idea; if you don't trust your site administrators to fill out the form properly, you've got much bigger problems. Plus, newforms-admin makes the whole thing moot, and just as 99% of post-queryset-refactor code I've seen has ignored everything except model inheritance (arguably one of the *less* interesting new features), I expect 99% of post-newforms-admin code will ignore the interesting feature and simply turn out to be "automatically fill in the user" tricks. Meanwhile, in public-facing forms for general (i.e., not necessarily trusted) users, it's ridiculously easy to automatically fill in a foreign key automatically. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: "request"object within models.py
On Mon, May 19, 2008 at 3:45 PM, Richard Dahl <[EMAIL PROTECTED]> wrote: > how do you pass the request object to models? Same way you pass any argument to any function or method in Python: write your function/method to accept the argument, and pass it from the code that calls the function/method. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: "request"object within models.py
On Mon, May 19, 2008 at 3:24 PM, enri57ar <[EMAIL PROTECTED]> wrote: > How access to request object within models ? Pass it as an argument the same as any other value. Magical hacks to try to make it available otherwise are likely to land you in trouble later on. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django experts wanted
On Mon, May 19, 2008 at 10:56 AM, Jim R. Wilson <[EMAIL PROTECTED]> wrote: > I am compiling a contact list of Django experts who may be interested > in opportunities under the right circumstances. I am not a recruiter > - I'm a regular developer who sometimes gets asked for referrals when > I'm not personally available. The site you're looking for is djangogigs.com. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Printing out HTML that doesn't get converted to
On Mon, May 19, 2008 at 12:51 AM, Tomás Garzón Hervás
<[EMAIL PROTECTED]> wrote:
> I think, you use the {% autoescape off %} text to escape {% endautoescape %}
> Search more information of autoescape en django documentation
Turning autoescaping on and off for large sections of a template is a
sort of sledgehammer approach. For specific variables, as the case
seems to be here, the "safe" filter is much more appropriate and
fine-grained.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Legacy Databases - custom filter?
On Sun, May 18, 2008 at 4:10 PM, Dougal <[EMAIL PROTECTED]> wrote: > How would I then do this SQL manually? I know writing SQL is to be > avoided but is there an easy way to execute SQL commands? Writing SQL is *not* to be avoided. Using an ORM is basically a trade-off, where some things are supported as ORM methods and some still require SQL (every ORM does this, even the most powerful ones). So if it looks like the Django ORM doesn't support the query you want to execute, you can do it manually, as documented: http://www.djangoproject.com/documentation/model-api/#executing-custom-sql -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: how to avoid uploading .py source files to shared hosting server
On Fri, May 16, 2008 at 11:52 AM, ydjango <[EMAIL PROTECTED]> wrote: > I do not want to make it easy for some one who breaks in , either a > outsider or may be an rougue hosting provider employee or contractor, > to easily get access to all the information - data and code. Again: if this is your worry, you have bigger problems. Allow me to suggest an alternate method: (satire begins here, for the humor-impaired) 1. Physically obtain the server upon which the code is stored. Write random data to the relevant sectors of the hard drive seven times over, then write zeroes to it seven times over, then write random data again. 2. Physically destroy the hard drive. Sledgehammers are good for this. 3. Place the shards of the hard drive into a vat of highly caustic acid. 4. Once the shards have dissolved, burn the resulting acidic liquid. Be sure to capture the smoke. 5. Cool the smoke until it turns back to ash. Mix the ash into the center of a reinforced concrete slab, at least 27 cubic feet in volume. 6. If you have access to sufficient technology, launch the concrete slab into space, on a course to collide with the Sun or (better) with any singularity which happens to be nearby. The singularity is best because -- even though it may not guarantee destruction of the information -- the subjective time to observe the rocket crossing the event horizon, from the frame of reference of a person some distance from it, will be effectively infinite, causing most attackers to give up. 7. If you do not have access to sufficient technology, have the concrete slab stored in a nuclear-hardened bunker, with no Internet connection, in a room using biometric identification keyed to yourself, and with the whole complex guarded 24/7 by US Navy SEALs. Maintain this watch until the technology available to complete step (6) becomes available to you. Once you've completed this process, your application code will be safe, for a reasonable value of "safe". (satire ends here) Or you could just find a host who properly sets up file permissions so that random people can't access your application code. Unless you own and personally supervise all of the following you will be susceptible to rogue employees: the server, the rack in which it's located and the datacenter in which the rack is found. Many people do not find that the perceived security gains of doing so outweigh the financial and maintenance drawbacks. YMMV. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: how to avoid uploading .py source files to shared hosting server
On Fri, May 16, 2008 at 9:15 AM, ydjango <[EMAIL PROTECTED]> wrote: > Yes, that was another thing on my mind, how to encrypt password in > settings.py You don't. I think either you misunderstand how shared hosting works, or you have an extremely bad host. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: how to avoid uploading .py source files to shared hosting server
On Fri, May 16, 2008 at 5:02 AM, ydjango <[EMAIL PROTECTED]> wrote: > I have propriety commercial code and some formula/ algo > implementations which I do not want to expose. > Hence I do not want to upload .py source files If your host's setup would allow other users to view this code, you have much larger and much more dangerous security problems to worry about (since, for example, that would mean they could also see sensitive passwords in configuration files). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: IntegerField - SQL type changed?
On Thu, May 15, 2008 at 5:34 AM, Amit Ramon <[EMAIL PROTECTED]> wrote: > Was there any change in django in the recent months that could explain this? > Namely, could it be that a couple of months ago django would indeed generate > a varchar(20) for this field, and now it generates int(11)? I'll bet money that at the time the table was created you were using Django's built-in PhoneNumberField, which is specified as VARCHAR(20): http://code.djangoproject.com/browser/django/trunk/django/db/backends/mysql/creation.py#L21 -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
ANNOUNCE: Security bugfix releases
In accordance with our security policy[1], a set of releases is being issued tonight to fix a security vulnerability reported to the Django project. This message contains a description of the vulnerability, a description of the changes made to fix it, pointers to the the relevant patches for each supported version of Django and pointers to the resulting releases. A copy of this information will also be posted on the official Django weblog, and the relevant areas of the Django website are being updated to reflect the new releases. Description of vulnerability: The Django administration application will, when accessed by a user who is not sufficiently authenticated, display a login form and ask the user to provide the necessary credentials before displaying the requested page. This form will be submitted to the URL the user attempted to access, by supplying the current request path as the value of the form's "action" attribute. The value of the request path was not being escaped, creating an opportunity for a cross-site scripting (XSS) attack by leading a user to a URL which contained URL-encoded HTML and/or JavaScript in the request path. Affected versions: * Django development trunk * Django 0.96 * Django 0.95 * Django 0.91 Resolution: The login form has been changed to escape the request path before use as the form's submission action. The relevant changesets for affected versions of Django are: * Django development trunk: Changeset 7521 (http://code.djangoproject.com/changeset/7521) * Django 0.96: Changeset 7527 (http://code.djangoproject.com/changeset/7527) * Django 0.95: Changeset 7528 (http://code.djangoproject.com/changeset/7528) * Django 0.91: Changeset 7529 (http://code.djangoproject.com/changeset/7529) The following releases have been issued based on the above changesets: * Django 0.96.2: http://media.djangoproject.com/releases/0.96/Django-0.96.2.tar.gz * Django 0.95.3: http://media.djangoproject.com/releases/0.95/Django-0.95.3.tar.gz * Django 0.91.2: http://media.djangoproject.com/releases/0.91/Django-0.91.2.tar.gz All users of affected versions of Django are strongly encouraged to apply the relevant patch or upgrade to the relevant patched release as soon as possible. Release manager's note: If you maintain a third-party Django package and you did *not* receive the announcement of these release from me earlier tonight, please email me directly as soon as possible. Also, please note that potential security vulnerabilities should be reported directly to the Django project, at [EMAIL PROTECTED], as outlined in our security policy[1]. Following this procedure helps us to maintain high standards of response and disclosure, and makes the process of investigating and resolving security issues much easier for everyone involved. [1] http://www.djangoproject.com/documentation/contributing/#reporting-security-issues -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Handle on request object from custom tag
On Fri, May 9, 2008 at 10:11 PM, Greg Fuller <[EMAIL PROTECTED]> wrote: > How do I get a handle on the request object from within a custom > template tag? By making the request available to the template as a context variable, then accessing it the same as any other context variable. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Group by for querysets
On Fri, May 9, 2008 at 12:47 PM, Chris <[EMAIL PROTECTED]> wrote: > Does django carry something similar to what I am looking for? If not, > would a group_by feature be something worth adding to django? If you're using a recent Django trunk checkout (after the queryset-refactor merge), there is some basic support if you go look at it. As of the qsrf merge, each QuerySet instance is backed by an instance of django.db.models.sql.query.Query, which represents the actual query to be executed, and that class offers a number of features which are not yet exposed as high-level API methods. The one you'll want to look at is the attribute 'group_by' of the Query class, which should be a list or tuple of either column names or additional Query objects; when the query is executed, the presence the 'group_by' attribute will become a GROUP BY clause in the SQL. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: /admin Cross-Site Scripting (XSS) issue!
On Wed, May 7, 2008 at 3:18 PM, Richard Dahl <[EMAIL PROTECTED]> wrote: > If I said that this condition is indicative of an XSS attack vector I > may as well say that Apache is vulnerable to a Denial of Service > attack because 'after I ran apachectl stop, I could no longer get to > my website' No, because someone else could put a link on their site to my admin with this sort of thing embedded. Yeah, it's a big reach in terms of the user needing to be completely braindead to fall for it, but it's possible and so we need to take it seriously. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: /admin Cross-Site Scripting (XSS) issue!
Also, for future reference, please remember that if you think you've found a security problem in Django the correct action is to send email to [EMAIL PROTECTED] -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: /admin Cross-Site Scripting (XSS) issue!
On Wed, May 7, 2008 at 2:51 PM, Richard Dahl <[EMAIL PROTECTED]> wrote: > Excellent, good catch, when logged out it does indeed display the > alert, I image it has to do with the 'next' property, which is not, I > believe, escaped, as it is not entered into the DB or presented to any > other user. So again, it begets the question: How is the XSS attack > possible? I'd imagine the big threat is actually not "scripting" per se, but the fact that you can tweak the URL that form submits to for a non-logged-in user. That user then, you hope, ignores the glaring warning of the URL and submits username/password to wherever you want him/her to send it. Easily prevented by users who have half a brain, but still needs fixing. I've cross-posted to django-dev to get it handled. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: /admin Cross-Site Scripting (XSS) issue!
On Wed, May 7, 2008 at 1:45 PM, mw <[EMAIL PROTECTED]> wrote: > It worked for me and I have one of the fairly recent copies from SVN. > (not like today up to date, but pretty up to date) Visiting the precise URL he pasted, in current Django trunk (SVN revision 7514), I get a 404. And I can't see any way that the URL would match something in a prior version of Django, since there's never been an admin URL pattern that can match "index.php". or the other junk in that URL. My best guess is somebody made a 404.html template and is displaying the raw path of the URL without escaping (or with escaping turned off, depending on the Django version). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django equivilent of PHP date in templates.
On Wed, May 7, 2008 at 2:06 PM, DuncanM <[EMAIL PROTECTED]> wrote:
> Would I have to create a template tag, or is there anyway of just
> sticking it straight into the template?
>
> Something similar to what the following php returns:
> date("F j, Y");
You probably want to read the list of built-in template tags in the
documentation.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: /admin Cross-Site Scripting (XSS) issue!
On Wed, May 7, 2008 at 12:31 PM, Chunlei Wu <[EMAIL PROTECTED]> wrote: > /admin/index.php/%22%3E%3Cscript%3Ealert%283939%29%3C/script%3E/ > > I am surprised the passed javascript code is indeed executed. Can > somebody verify that? Is it a big threat? Which version of Django is this happening in? Automatic default escaping of template contents didn't start until after the 0.96 release... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: child edit causes duplication with model inheritance
On Sun, May 4, 2008 at 3:29 AM, bobhaugen <[EMAIL PROTECTED]> wrote: > Does that mean newforms-admin includes qs-ref? That is, newforms- > admin includes all of the most current svn trunk? The ideal way to find out this sort of information is to watch the development timeline: http://code.djangoproject.com/timeline And specifically the log of the newforms-admin branch: http://code.djangoproject.com/log/django/branches/newforms-admin -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: child edit causes duplication with model inheritance
On Sun, May 4, 2008 at 12:58 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > if you add an "A" object then edit it and hit save it duplicates > itself. Does anyone else have this trouble with model inheritance? The admin does not currently support model inheritance. This is a known and documented issue, and is being worked on. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django-tagging doesn't work with qs-ref
On Fri, May 2, 2008 at 1:05 PM, bcurtu <[EMAIL PROTECTED]> wrote: > How can I solve this parse_lookup problem? > Cheers Have you considered looking at that project's bug tracker? http://code.google.com/p/django-tagging/issues/detail?id=106=1=queryset-refactor -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: HEAD requests causing AttributeError
On Thu, May 1, 2008 at 4:39 AM, omat <[EMAIL PROTECTED]> wrote:
> I don't see why someone / something is hitting with HEAD requests. Can
> it be a security issue?
No, it's not a security issue. It probably means you've enabled the
middleware view-documentation middleware
("django.middleware.doc.XViewMiddleware") but don't have the auth
middleware ("django.contrib.auth.middleware.AuthenticationMiddleware")
enabled as well.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: persistence of variable in views.py
On Thu, May 1, 2008 at 1:23 AM, skunkwerk <[EMAIL PROTECTED]> wrote: > I have a variable defined by a function call in my views.py that's at > the global level at the start of the file (ie is not inside any other > function, though the variable is not prefixed by 'global'). As this > takes a few seconds to complete, I just wanted to make sure that this > function isn't being called every time a new url is requested. django > only loads views.py once and then calls whatever functions necessary, > correct? Yes and no. In theory, under a production setup, the module containing your views will be initialized only once per server process, and will remain in memory for the life of the server process (so, for example, if you have one server process with MaxRequestsPerChild set to "100", it would be initialized once per 100 HTTP requests). In practice, it may be initialized multiple times depending on how you've written your code, specifically depending on the import statements being used. When you type, for example:: from myapp.views import some_view for the first time, Python will locate the necessary file and initialize it by executing the code within; this will define the view functions, and also define your global variable. Then the resulting object (a live Python module object) will be inserted into the dictionary "sys.modules" under the key "myapp.views". Later, if you import again, Python will find "myapp.views" as a key in "sys.modules" and use the already-initialized module object there. The problem is that if you later do, say:: from myproject.myapp.views import some_view then Python will be looking in "sys.modules" for the key "myproject.myapp.views", which won't exist; it will go out and find the file again, initialize it again, and store the resulting module object in "sys.modules" under the key "myproject.myapp.views". The net result is that Python will initialize the module once for each different "path" (e.g., "myapp.views", "myproject.myapp.views", etc.) you use in an import statement. This is, incidentally, what trips up so many people with newforms-admin at the moment -- when they reference the same module in a different way, it gets initialized again and triggers an error as a model tries to re-register its admin interface. To avoid this, ensure that you use import statements consistently. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Backwards incompatibility with fancy PostgreSQL queries and QS-RF
On Wed, Apr 30, 2008 at 11:43 PM, Barry Pederson <[EMAIL PROTECTED]> wrote: > any thoughts on the best way to do this now with QS-RF? Well, the official database API docs say [1]: "In some rare cases, you might wish to pass parameters to the SQL fragments in extra(select=...)`. For this purpose, use the select_params parameter. Since select_params is a sequence and the select attribute is a dictionary, some care is required so that the parameters are matched up correctly with the extra select pieces. In this situation, you should use a django.utils.datastructures.SortedDict for the select value, not just a normal Python dictionary." And the branch notes for queryset-refactor say [2]: "Still on extra(select=...)... if you want to substitute parameters into these extra selection columns, use the select_params argument to extra(). The params argument is only applied to the extra where conditions." And the backwards-incompatible changes page [3] points to the above notes on the branch description page. [1] http://www.djangoproject.com/documentation/db-api/#extra-select-none-where-none-params-none-tables-none-order-by-none-select-params-none [2] http://code.djangoproject.com/wiki/QuerysetRefactorBranch#Other [3] http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges#Queryset-refactormerge -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django on Jython - anybody doing it?
On Wed, Apr 30, 2008 at 9:44 PM, rich <[EMAIL PROTECTED]> wrote: > More out of curiosity than anything else, is anybody using Django on > Jython? Several people are, and are actively involved in improving both Jython and Django to work better together; a number of bugs have been reported to both projects (most of them worked out by now), and Leo Soto (who's done a lot of unsung work to keep things rolling) is doing a Google Summer of Code project dedicated to that: http://code.google.com/soc/2008/psf/appinfo.html?csaid=DA6AC3DE94E157E -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Queryset-refactor branch has been merged into trunk
On Mon, Apr 28, 2008 at 8:32 AM, Juanjo Conti <[EMAIL PROTECTED]> wrote: > Could you give me a url where new features are explained? > Is this backwards compatible or should I svn up with care? Well, there's the wiki page Malcolm linked up in his original post... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Odd Multi Select Behavior
On Sun, Apr 27, 2008 at 1:39 PM, Alex Ezell <[EMAIL PROTECTED]> wrote: > but if I log the value of "request.POST['point_list']" I see this: > > 37.4482804,-122.12251 > > It's like it doesn't know that it's a list. This makes it problematic > to do anything with the values in point_list. http://www.djangoproject.com/documentation/request_response/#querydict-objects -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Updating django forms makes me...
On Sun, Apr 27, 2008 at 10:28 AM, notfound <[EMAIL PROTECTED]> wrote: > What could be the reason here that it sometimes works, sometimes does not? Multiple server processes; each one has its own copy of the code, and refreshes independently. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: SUM on a model
On Sun, Apr 27, 2008 at 8:47 AM, Darryl Ross <[EMAIL PROTECTED]> wrote:
> I use:
>
>total = sum([obj.amount for obj in Model.objects.all()])
As of the merge of qsrf, this will also work:
total = sum(Model.objects.values_list('amount', flat=True))
Plus there's the SoC project which will be building high-level
aggregate support over the summer; for now the above solution isn't so
bad for performance (sum() is done in C with some neat optimizations,
if you ever look at the code). And, of course, you can always drop
down to raw SQL and feed a SELECT SUM directly to the DB.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Updating django forms makes me...
On Sun, Apr 27, 2008 at 7:17 AM, notfound <[EMAIL PROTECTED]> wrote: > No, that's a hosted server, I don't have access to Apache > unfortunately. Is there any other way I could make it reload the code? Not really, no. In a production deployment, the code stays resident in memory for the life of a server process, and does not (for performance reasons) automatically reload any time you change a file. Which means that when you make a change, you have to restart the server process. If your hosting doesn't let you do this, you probably need a different hosting arrangement. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Disabling autoescaping when calling render_to_string
On Sat, Apr 26, 2008 at 9:38 PM, Darryl Ross <[EMAIL PROTECTED]> wrote: > So my question is, is there an argument which will disable auto-escaping? > If not, would there be some merit to adding some functionality that allows > this, either as an argument or perhaps to make the auto-escaping only > auto-escape if the template filename ends in '.html'? No, and probably not. One of the key things about Django's autoescaping is that, since it applies in the template, you can look at the template to find out what's going on. Introducing lots of other places where you'd need to look, transforming it from "look at the template to see if the autoescape tag or the safe filter are used" to "look at the template, then look at this argument, then look at this setting, then..." would be a disaster. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: 'dict' object has no attribute 'autoescape'
On Wed, Apr 23, 2008 at 6:59 PM, falcon <[EMAIL PROTECTED]> wrote: > 94. if (context.autoescape and not isinstance(output, > SafeData)) or isinstance(output, EscapeData): Right there's your problem. you've ended up passing a plain dictionary someplace where Django was expecting you to pass an instance of Context. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: how do designers create content
On Sun, Apr 20, 2008 at 1:33 AM, lee <[EMAIL PROTECTED]> wrote: > designers. Do the designers use text base editting like ultraedit or > or graphics based software like dreamweaver? Most of the artist I know > don't do much coding and are into photoshop, illustrator and > dreamweaver. Most of the designers I've worked with mock things up in Photoshop, then bust out TextMate to do the HTML and CSS. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: mail in base64
On Thu, Apr 17, 2008 at 10:16 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > (1) What version of Django are you using (the mail infrastructure has > changed a bit between 0.96 and trunk, from memory)? He was using Django 0.96, and running into this (fixed on trunk) issue: http://code.djangoproject.com/ticket/3472 -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Enterprise applications with Django
On Wed, Apr 16, 2008 at 8:05 AM, Hussein B <[EMAIL PROTECTED]> wrote: > Is it possible to create enterprise applications (in the same context > of Java EE applications, highly concurrent, distributed ...) with > Python? Google seems to manage it... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
