Re: How to server static media secured by Django authentication
At 11:49 PM -0600 9/11/09, Gabriel Gunderson wrote: >On Fri, Sep 11, 2009 at 3:03 PM, Jim Myers wrote: >> I have a requirement to serve static files only to users authenticated >> through Django secure login. > >http://docs.djangoproject.com/en/dev/howto/apache-auth/ I've got a similar, but slightly more complex need... I need to serve some static files (pdfs etc.) to any authorized user, other static files to members of group A (as in Django), and other static files to members of group B. It would seem that I could create some specific permission name for group A and another for group B. I'll put each set of files into a unique directory / url as need-be. I was hoping that my friend who wrote the Django code for this site would tweak this for me a couple of weeks ago since I haven't dealt with the Django code for ages and ages and feel like I'm back to a complete newbie. So... the naive questions are: 1) how do I configure each different directory in Apache's conf file to require a different permission name? ( 2) where do I put the PythonOption directives ? e.g. DjangoPermissionName 3) in the example cited above, am I correct that I need to change "mysite.settings" to whatever I set DJANGO_SETTINGS_MODULE to actually? 4) is it really going to be just that simple... as described in that howto? (he asks hopefully -- right now I need a simple "do this, then that, then this") Thanks -- Glenn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=.
Re: Django meetup in San Francisco this Thursday?
On Mon, Dec 18, 2006 at 11:29:18AM -0600, Adrian Holovaty wrote: > I'll be in San Francisco later this week. Anybody interested in having > a Django meetup Thursday night? I know that a couple of us on the Peninsula (between SF and San Jose) would like to get together if we can... Are you talking about being in SF proper, or "in the Bay Area"? Whenever / wherever you decide, please let us know... maybe one or both of us will be able to make it. -- Glenn Tenney --~--~-~--~~~---~--~~ 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: Off Topic: Mac software for database design?
On 4 Aug 2006, at 19:35, Joseph Heck wrote: > I believe it was a little custom script that generated a schema > model in OmniGraffle from the ruby code. Not 100% sure, but I > recall seeing one of the local ruby guys using it. Back in April I posted here: Subject: pictorial representation of models? In my reading up on Ruby on Rails, I found a link to a page on the RoR wiki that shows a pictorial representation of a schema (model) along with documentation etc. See http://wiki.rubyonrails.org/rails/pages/AccessControlListExample/versions/25 Does anything like that exist to take a Django model and automatically generate a picture of that schema??? I think it would be a BIG help... to which Russ Magee responded: 1) I don't think the Rails guys have an automated tool, either :-) The Rails diagram you reference looks suspiciously like it might have been hand drawn using the Core Data designer from XCode (not unlikely given that the 37Signals guys - or at least DHH - use Macs). 2) The best graph autolayout tool I know of is GraphViz (http://www.graphviz.org/)- it's open source, and works off a well documented input format. I haven't looked into it extensively, but writing a Django Model->DOT converter shouldn't be too hard - might be a nice little project if someone is looking to get intimate with Django model internals. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django source editing offtopic
On Tue, Aug 01, 2006 at 04:29:02PM -0700, Joseph Heck wrote: > On the Mac, I used TextWrangler Yep, very nice... But I mostly just use emacs (which comes with Mac OS X, as well as "vi" if you're so inclined). -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: mod_python autoreload acts unpredictable
On Fri, Jul 07, 2006 at 10:22:12AM -0700, x0nix wrote: > Well ... I don't like the idea of every programmer (after every minor > change) logging in as root to production server. You shouldn't have your programmers logging in to a production server to do testing even if there were no issues about mod_python. All the testing and QA should be done on a different machine, be it your development machines or a separate staging server (depending on how you run your "shop"). In an ideal world, your programmers would develop and test on development-only machines, then pass the tested code over to a QA group who would test it again (a different level of testing) on a staging server, and then finally the QA group would move the fully tested code over to the production server. -- Glenn Tenney CISSP CISM --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: after_acreate after_change
On Tue, Jul 04, 2006 at 10:10:55AM +1000, Malcolm Tredinnick wrote: > I can't see any real advantage in this. As Ivan shows, it's only a > couple of lines of code anyway (and a more or less documented feature). > The boolean test for "not created" at the moment is "if not self.pk:", > which seems pretty reasonable. Thanks. Fine by me. I was just worried that this might be a use of a "hidden" behavior that might at some point become non-supported or something (who knows, with MSSQL or transactions or something weird that suddenly makes that behavior no longer mean that the db object hasn't been created). -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: after_acreate after_change
On Mon, Jul 03, 2006 at 07:09:35AM -0500, James Bennett wrote: > You can also differentiate between the initial save and later updates > by checking -- before calling the parent class' 'save' method -- > whether the object has an ID; if it doesn't, then the object is being > created for the first time, and if it does then it's an update to an > existing object. Perhaps instead of relying on the behavor of the object's ID not existing until it's been created, that should become a method. something like Model.created() returning true/flase or Model.is_created or... something...??? -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Repetitive background tasks
On Mon, Jun 26, 2006 at 06:07:19PM -, Harish Mallipeddi wrote: > Is there a way to do this by resorting to a solution within the django > framework and not some OS-level solution like cron jobs on Linux? As has been mentioned, using cron (or cron-like) to schedule running a Python script is a great solution... but there are other ways that might work for you too. 1) Within your application, write a "view" that doesn't necessarily view anything, but instead it does all of the functionality you need for this repetitive task... then... Still using cron functionality, you have some machine somewhere in the world (or on your internal LAN with appropriate ACLs and firewalling) go to a specific URL that executes that "view" to do the repetitive tasks. or 2) Also within your application, write a global function that (a) immediately checks to see if it's the first time it's invoked each day (or whatever interval), and then, if it is the first time, (b) does all of the repetitive tasks... This translates to: the first click within the desired interval automatically performs the pending repetitive tasks. Note: this is not always a good solution (but can sometimes be fine), since you might have tasks that need to be done every interval even if no one clicks your site, or the tasks run a long time, etc. This can be combined with #1 above in that the URL in #1 above would only need to be some regular URL into your application since ANY click to your application will do the repetitive task once each interval. -- Glenn Tenney CISSP CISM --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: null=True conditionally
On Sun, May 21, 2006 at 10:17:52AM +1000, Malcolm Tredinnick wrote: > If you also want to say "it is optional to enter this in the admin > interface", then you also need to set blank = True on the field (this > won't require any change to your database: it only affects the > interface). Perhaps the option "blank" should not even be used -- use "required=False" instead of "blank=True" (and vice versa of course)... i.e. isn't it more clear to say that entering some value for this field either is or is not required...? -- Glenn X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.54.131.8 with SMTP id e8mr162423wrd; Sat, 20 May 2006 23:16:38 -0700 (PDT) Return-Path: <[EMAIL PROTECTED]> Received: from zardoz.think.org (gateway.think.org [205.179.127.12]) by mx.googlegroups.com with ESMTP id v23si580662cwb.2006.05.20.23.16.37; Sat, 20 May 2006 23:16:38 -0700 (PDT) Received-SPF: pass (googlegroups.com: domain of [EMAIL PROTECTED] designates 205.179.127.12 as permitted sender) Received: from zardoz.think.org (localhost [127.0.0.1]) by zardoz.think.org (8.12.3/8.12.3/Debian-7.2) with ESMTP id k4L6Ga02010261 for ; Sat, 20 May 2006 23:16:36 -0700 Received: (from [EMAIL PROTECTED]) by zardoz.think.org (8.12.3/8.12.3/Debian-7.2) id k4L6GaSK010259 for django-users@googlegroups.com; Sat, 20 May 2006 23:16:36 -0700 Date: Sat, 20 May 2006 23:16:36 -0700 From: Glenn Tenney <[EMAIL PROTECTED]> To: django-users@googlegroups.com Subject: Re: null=True conditionally Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain In-Reply-To: <[EMAIL PROTECTED]> On Sun, May 21, 2006 at 10:17:52AM +1000, Malcolm Tredinnick wrote: > If you also want to say "it is optional to enter this in the admin > interface", then you also need to set blank = True on the field (this > won't require any change to your database: it only affects the > interface). Perhaps the option "blank" should not even be used -- use "required=False" instead of "blank=True" (and vice versa of course)... i.e. isn't it more clear to say that entering some value for this field either is or is not required...? -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Install woes: error "python: can't open file 'django-admin.py' "
On Fri, May 05, 2006 at 06:23:48PM -, jbrewer wrote: > But when I used DarwinPorts of SQLite it installed Python 2.4 here: > > /opt/local/bin - and located here also is sqlite3 Remember, I said to look at ALL of the comments from http://www.djangoproject.com/documentation/install/ which includes: "Additional note on pysqlite 2.1.3 on Mac OSX. If you installed the newest sqlite3 via darwin ports, your header files and libraries are in /opt/local/include and /opt/local/lib respectively. Before you build/install pysqlite manually, you need to modify pysqlite's setup.cfg accordingly so that it will pick up on the new library instead of OSX's default sqlite 3.1.3 installation." There are other comments about Mac OS X, and darwin ports of sqllite... etc. Have you tried everything noted in all of those comments? p.s. This shows that a Mac OS X install section would sure be nice... -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: create models from the admin page?
On Fri, May 05, 2006 at 12:20:35PM -0500, James Bennett wrote: > Keep in mind that's a wiki that *anyone* can contribute to, not just > "official" developers ;) And... because it's a wiki... have their contributions deleted too. (mine were) -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Install woes: error "python: can't open file 'django-admin.py' "
On Fri, May 05, 2006 at 12:32:23AM -, jbrewer wrote: > I have tried to install the MySQLdb and keep getting this error: > > error: command 'gcc' failed with exit status 1 1. Read http://www.djangoproject.com/documentation/install/ 2. Follow all of the comments talking about Mac OS X (this is the key -- you've got to read the comments on that page!!!) 3. Use SQLlite I did and it just worked... very easily... no pain... -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Three models linked together: how do i do (...) ?
On Thu, May 04, 2006 at 10:32:59PM +0200, Moi Meme wrote: > And on my particular ticket system case, Paul Bissex's 20 mn trouble > ticket system (http://e-scribe.com/news/230) looks cool, but is limited > to one model, which takes its list of applications from a static list > (INSTALLED_APPS). Paul's trouble ticket example takes its list of applications from the list of applications your running Django system knows about... that "INSTALLED_APPS" is from the configuration for the running system. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: get parameters in template
On Thu, May 04, 2006 at 12:43:23PM +0200, [EMAIL PROTECTED] wrote:
> Is if possible to define easily a set of static variables that will be
> available inside the templates ?
I know that you're seeking a solution for generic views, but just fyi
here's what I did for my custom views to do this:
In the view I set up a function to allow me to check for and validate
such parameters (e.g. "...sort=xyzzy"). You don't NEED to have a function
for this, but I believe that you definitely should validate these parameters.
def check_arg(request, arg, default, valids):
result = request.GET.get(arg, default)
if result not in valids:
result = default
return result
Then, in each of my views where I might have some parameter I add
something like:
sort = check_arg(request, 'sort', 'name', ['name', 'rating'])
or
view = check_arg(request,'view', 'top', ['top', 'all'])
or
display = check_arg(request,'display', 'full', ['full', 'brief'])
and finally, in each of those views you need to add each "parameter"
variable (e.g. "sort" above) to the context with something like:
c = DjangoContext(request, {
"sort":sort,
"view":view,
"display":display,
"obj_list":obj_list,
}, None)
Then, in your template you refer to these variables just like
{{ sort }}
Hope that helps even though it's not generic views...
--
Glenn Tenney
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: got unexpected keyword argument
On Sat, Apr 29, 2006 at 08:20:30PM -0500, James Bennett wrote:
> In the tutorial, the field on the Choice model ('poll') is the same as
> the name of the model it's being related to ('poll'), which is why it
> looks that way. Whenever they're different, you want to use the name
> of the field on your model.
Which is why I said a few weeks ago that the choice of field and class
names for the tutorial must be such that there can be no confusion
(this is a learning example), and the way that field and class names
are documented should be exceedingly clear too...
--
Glenn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: BooleanField and MySQL default value
On Sun, Apr 23, 2006 at 03:14:15PM -0500, Adrian Holovaty wrote: > Default values aren't created at the SQL level -- they're enforced at > the Django DB-API level. I thought that was only enforced by the admin functionality and that if I wanted a default value for my views I'd have to write it myself into the model or view. I found it unclear to me which field settings were enforced by the admin functionaility, the DB-API, or the SQL DB level. This should be made VERY clear in the docs, and when within the DB-API it should also be crystal clear when/how to override either that functionality or the method within which that enforcement is done (and then, when overriding those methods how to invoke the parent's methods too). -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Passing variables to include? (and New call tag)
On Fri, Apr 21, 2006 at 09:38:56AM +0400, Ivan Sagalaev wrote:
> You use it then like this:
>
> {% product bestOffer %}
>
> ... and bestOffer will be passed in product.html by the name 'product'.
And
On Fri, Apr 21, 2006 at 10:16:29PM +0800, limodou wrote in re:
Subject: New call tag
> It just like include, but in order to distinguish with
> "include" tag, I call it "call". So you can use it:
>
> {% call "some.html" %} this way just like include tag, and the advanced way:
>
> {% call "some.html" with "a" "b"|capfirst title="title1" %}
> {% call "some.html" with "c" "d" title="title2" %}
>
> So you can see, "call" tag can do like a python function, it can
> receive tuple parameters and key word parameters, just like the
> function:
>
> def func(*args, **kwargs):pass
There's a pattern here... a need for more "programability" in the templates.
I for one believe that templates should NOT have Python (in the case
of Django, or Ruby in the case of Rails) in them -- PERIOD! A very
bad thing to do, security-wise.
The other pattern that emerges here is that there's a need for
being able to at least set variables from within a template.
I propose adding a tag to Django (i.e. not just "write your own
template", but make it, or something like this, a part of Django) for
just that purpose:
{% set variable value %}
where value is parsed so that it can be either a string
or another variable name or of the form a.b.c etc.
in Ivan's case one would just do:
{% set product bestOffer %}
{% include product.html %}
and, in limodou's case one would just do:
{% set title "title1" %}
{% include some.html %}
This would allow one template to pass lists, or objects within
lists or whatever to other included templates. It's not as
"elegant" as passing arguments to templates as what limodou
has done, but it will get that job done; be useful in other
ways; not have Python code in templates; and is fairly simple
and straightforward.
--
Glenn Tenney
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
pictorial representation of models?
In my reading up on Ruby on Rails, I found a link to a page on the RoR wiki that shows a pictorial representation of a schema (model) along with documentation etc. See http://wiki.rubyonrails.org/rails/pages/AccessControlListExample/versions/25 Does anything like that exist to take a Django model and automatically generate a picture of that schema??? I think it would be a BIG help... -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django vs Rails
On Thu, Apr 13, 2006 at 07:17:16PM -0700, [EMAIL PROTECTED] wrote: > There is only one Rails book that is in print at the moment(non pdf). > There are several others that are going to be released very soon > though. http://www.robsanheim.com/2006/03/23/ruby-and-ruby-on-rails-book-roundup/ is a blog showing something like 16 Ruby and Rails books out now or out "real soon now". Searching on Amazon for "ruby rails" gives quite a few books (I counted NINE Ruby on Rails books) due out within about the next six months -- who knows if they'll slip or not. Solid reliable up-to-date accurate complete documentation (without having to rely on reading through the code itself and/or code examples) is critical! To some, that means multiple books being available (not always worth anything, but some people just want to see books available on Amazon... period); to others, it doesn't matter if it's one book, half a dozen books, or downloadable files... so long as it IS available. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ecommerce & Django
A group with which I volunteer is a Cold Fusion shop. One of the other volunteers used EZ-Cart for a few ecommerce sites and loved it. You might want to see the features it has... See http://www.cf-ezcart.com/ -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django vs Rails
Several friends have been pushing me to look at Rails, so I've been reading through "Agile Web Development with Rails". Some quick thoughts... with a couple of questions thrown in... 1. Ok, there IS the Ruby vs Python thing... I'll leave that to some *other* place for THAT flame fest as I do NOT want that here! 2. In Rails you need to declare your SQL code *and* tell Rails about your schema, but in Django it's all very nicely put into an object oriented description in your model. A big win, to me, for Django. 3. Rails supports and integrates well with Ajax. I know that this is "coming" for Django... sometime "real soon now"... how's it going? When might it be out? 4. Rails has built-in unit and functional testing support. I don't know, but I'd venture a guess that few Rails apps actually USE the built-in testing capabilities, but it *IS* very nice... Is there anything like that planned for Django? 5. Rails has a book or two already out there -- and already out of sync with the version of Rails recently released. Django's book is "in the pipeline" but I doubt it'll be out until 0.92 gets released. Any other major differences that I missed? -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On Tue, Apr 11, 2006 at 04:16:09PM -0400, Max Battcher wrote: > "pass" is the Python "do nothing" command, which is often used as an > indicator to "fill in the blanks" with your own specific code (because > Python doesn't allow empty functions it is often seen in psuedo-code). yes... yes... I know that... > I don't think it implies that you shouldn't raise an exception, after > all raising an exception is valid Python code. But that's not the point for documentation and examples of how to use something like Django... the docs and examples should show how to do it right -- or at least the expected way to do something or a "good" way to do it. I maintain that just not saving and doing nothing is not an example of how one should handle such a case. Unless an example shows raising an exception in this case, one might, not unreasonably, think that perhaps one should never raise an exception at that point in the process (e.g. "gee, it's too late to raise an exception, Django must expect me to let the user know in my view instead of in the model"). -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On Tue, Apr 11, 2006 at 06:19:49PM -, arthur debert wrote:
> the thing is, if there's anything in django's knowledge to avoid the
> save / delete it DOES raise an error. (such as trying to delete an non
> existant object or trying to save a model that does not pass
> validation). my guess here is if you need anything else in you logic
> that django doesn't know about (from validators and the db) you must
> implement it yourself.
Thanks.
I was my understanding that validators were a "view" thing... even
though you define the validator_list in the model. I thought that
because the data passed to a validator is NOT the actual data that
will be stored into the field(s) in question.
i.e. from http://www.djangoproject.com/documentation/forms/#validators
"Note that at the point validators are called all data will still be
strings (as do_html2python hasn't been called yet)."
So... are validators called automatically before any data is stored
into a model's "field"? Or, are the validators actually called only
as part of the form / view
> try:
> amodel.delete()
> except:
> return HttpResponseRedirect("bad_detele_action")
>
> or something to that effect.
Right... I can write all of my save/delete/etc. code around a "try".
But shouldn't this be a part of the "official" api -- either all such
destructive methods might raise an exception (so you should be
prepared for it), or all such destructive methods must return a
boolean indicating success/failure (and you should check for it)...
Plus, if I do code it that way, then how will the admin work against
my models that raise exceptions Will the admin try for exceptions
in save etc.? (sorry, but because I had one bad __repr that didn't
return a string and it did NOT get caught by a "try", I'm not making
any assumptions...)
> maybe the so called validation aware models in m-r will do it?
> http://groups.google.com/group/django-developers/browse_frm/thread/4bc65cf676c93846/5d7db0f7a5f85006?q=validation+aware&rnum=2#5d7db0f7a5f85006
I like the idea that the model should use a validator... but... is
that the way it DOES work in M-R? Do all "fields" of a model actually
invoke their validators?
--
Glenn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On Tue, Apr 11, 2006 at 02:24:04PM -0400, Max Battcher wrote: > You are free to raise your own exception in the path that fails to > call super().delete() in M-R. Then perhaps the docs etc. should instead show "raise " instead of "pass"... When one shows as an example to use "pass", it misleads some to think that one shouldn't raise an exception. Are there any other problems that might crop up if any of save / delete / etc. do raise some exception? e.g. will admin still work, just telling the user that it didn't work instead of some cryptic back-trace debug output due to an unexpected exception? -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Using _pre_delete() to stop execution
On Tue, Apr 11, 2006 at 05:01:39PM -, arthur debert wrote: > more on this here: > http://code.djangoproject.com/wiki/RemovingTheMagic#Addedamorepowerfulwayofoverridingmodelmethodsremovedhardcoded_pre_save_post_saveetc. Everything that I read there shows that you can choose to save or not-save, delete or not-delete, etc... which is fine, but I don't think goes far enough. I wouldn't want attempts to save/delete/insert/whatever to just not happen with everything else seeming to be fine, and with no ability to get an error message of some sort to the user. Shouldn't there be a way to signal that the save/delete/etc. did or did not work ok? Either by raising an exception or by returning a success / failure result... Or is that in M-R and I missed it...??? -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Overthinking urls.py?
On Thu, Mar 30, 2006 at 03:07:01PM -0500, Max Battcher wrote: > I hate to say it, but Routes and most of the other schemes presented > _do_ feel over-engineered. The current URL patterns system is fast > and clean. The get_absolute_url() pattern is simple one, and yes it > might break the "perfect Model seperation", but Django makes no qualms > that it absolutely has to follow MFC or PCMEF or whatever else, but > instead keeps in mind a good idea of what is "pragmatic". Earlier this week I noted that I believe get_absolute_url just does not belong in the Models... period. I suggested an alternative that I think would be easy to use, easy to implement, and would "fit". I didn't however, try to suggest the exact Django way to describe it since I was specifically trying to NOT get bogged down into that naming / implementation idea, rather to let the developers mull on it as one idea to consider. But, it didn't seem to get any comments pro or con, so let me try again: I believe that the Model should have a common method used to get a PART of a URL, the part that locates this object. That part of the URL might be "place/" or "poll/". But that is not an absolute url. It would then be up to the view (in a generic view, that should be handled by a dict entry) to pre-pend something in front of what the model provide to make it a URL. perhaps: In Models:get_url() returns a string that can be used by the view to make up a URL that uniquely identifies this object. In urlsconf: add to "infodict" -- 'url_view': 'polls' In the view: you form a url from: URL_BASE + 'url_view' + get_url() ( URL_BASE might not even be needed ) -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Overthinking urls.py?
On Tue, Mar 28, 2006 at 08:44:48PM +0200, Arthur wrote: > That's similar to what I do. The get_absolute_url() concatenates a > _BASE_URL from settings.py or from the top of models.py with > what you call get_id_for_url. This isn't completely clean but easy to > change if you remember where to look for the constant. Because the "url" for an object might be different depending on how you wanted to "see" that object (i.e. depending on the current view), in your way you'd have to make "get_absolute_url" not actually be the ABSOULTE URL... and THAT is the point in what I was suggesting. That the part of the URL "in front" of the object's unique part is not a constant for the entire settings.py, but rather is variable based on the view / tempalte. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Overthinking urls.py?
On Tue, Mar 28, 2006 at 12:19:39PM -0600, Jacob Kaplan-Moss wrote:
> "correct" and just as simple, and each time I've failed. As far as
> I'm concerned, if someone can come up with a way to do this that's
> stupidly simple then I'm all for a change, but at the same time
> get_absolute_url() is a wart I'm willing to live with.
Just thinking aloud...
In the model you want to know "what is this object's identifier that
we would use in a url". That might be just an object ID, a slug,
or maybe /mm/dd/id or who knows what. This would be formated
such that it could be used as-is as PART of a URL. Let's call this method
"get_id_for_url()" (or whatever you end up calling it) That seems to be
the appropriate type of data to come from a Model.. i.e. not the entire
absolute URL, but just a portion of the URL that would be used to
identify this Model's object.
Then, in the particular view (not clear, it might be and/or in the
template) you would want to combine some base URL string with the
previous get_id_for_url string to make it into a real url. To do that
might need just a variable "base_url" (or it could be yet another view
specific method) that changes by the view.
So in a template you'd have to do
{{ base_url }}{{ this-object.get_id_for_url }}
In your urls.py and/or view you'd setup a dict to pass the appropriate
value to the template e.g.
info_dict = {
'app_label': 'myapp',
'module_name': 'mymods',
'base_url': 'mymods',
}
That would allow me to use the generic views if I sent the 'base_url' correctly,
or you could even have it default to the 'module_name'. Or I could code
it into my view's code however I wish.
?
--
Glenn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: ASCII or PDF version of docs?
On Tue, Mar 28, 2006 at 11:11:58AM -0600, Adrian Holovaty wrote: > Alternatively (or maybe additionally), we could have a separate > downloadable tarball of all the docs in HTML format, with all the CSS > and images. I would prefer not to include all of that in the main > Django distribution, because it's a lot of cruft. Regardless of whether you include all the html/css or not, or the ability to create it after you un-tar a release package, the key point I was trying to make is: The portion of the online doc covering the models (at http://www.djangoproject.com/documentation/models/ ) is a critical and absolutely necessary part of the documentation as it now exists. The examples are not merely "examples", they include some documentation that does not appear anywhere else in the docs. Making the html/css or even pdf a separate download component is fine, but the docs as part of the base tar file of Django must include all the docs -- and that must include the example docs too. ---OR--- the docs need to be rewriten to bring the documentation aspects of all the examples into the "docs" another way. Thanks -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ASCII or PDF version of docs?
On Sun, Mar 26, 2006 at 10:40:53PM -0600, Adrian Holovaty wrote: > On 3/24/06, Glenn Tenney <[EMAIL PROTECTED]> wrote: > > You don't get all of the model examples -- and some of the > > needed documentation is in the example pages surrounding the actual > > examples. > > That's incorrect; you do indeed get the model examples. Although it's > not obvious, they're in the directory tests/testapp/models directory > of the Django distribution. The model examples are generated > automatically from the unit tests. First, aha! Thank you!!! There are some examples in the tar file! Who would have thought of looking in "tests" for "examples"? However... Those example files are NOT the same as what's in the online docs. For example: Look at http://www.djangoproject.com/documentation/models/many_to_many/ then look at Django-0.91/tests/testapp/models/many_to_many.py and see if in both files you can find the strings: "Sample API usage" or "Publication objects have the following methods" or "get_article()". You will find those strings in the online docs, but NOT in the example.py file. And that's part of the documentation that is MISSING from the tar file. Are these examples helpful? Certainly, but... (a) they need to be in a different and much more obvious location... oh, in the docs directory would be a start. (b) they are not the complete text of what's online and the parts that are missing are in fact critical to one trying to learn Django. I maintain that all of the online docs need to be in the tar file... -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Overthinking urls.py?
On Mon, Mar 27, 2006 at 04:21:09PM -0600, Adrian Holovaty wrote: > The convention is to put the URL-creation logic in your models, in a > get_absolute_url() method. Here's a quick example: > ... > You're right to imply that this goes against the DRY principle, > because you have to define URLs in two places -- the URLconfs and the > models. In practice, this isn't that big of a deal (in my humble > opinion), but we've given some thought to putting the > get_absolute_url() logic in URLconfs instead, so at least the logic is > in a single file. I believe that anything to do with a URL certainly does NOT belong in the model. Models are, in part, an abstraction of the data... the scheme... etc. Models should have nothing to do with the URL for an object! And that has nothing to do with whether the data appears in one or many places... the Model just isn't the right place for this data to be defined. While I know that the URLconfs is Python code, it doesn't seem that that's the right place either... from an abstraction point of view. The place that seems "right" is in the view itself... or perhaps actually at the template level. If in the view, it would need the URLconfs passing to the view the "base" of the URL that matched this view (or a dict or something, not necessarily the actual RE match!). Even doing it in the view will be "tough" since: a) different objects displayed in a view might have very different URL paths -- paths "outside" the view. b) normally it's the template that's actually displaying or making use of the URL of an object. A template T1 may want the url of object X to be different than that same object when displayed in template T2. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Recursive(?) ManyToMany model
On Mon, Mar 27, 2006 at 12:37:54PM -0800, wam wrote: > Well, it was my understanding that since I have the potential of having > many 'inspired by' documents linked to a particular document, and that > any particular document could have inspired many other other documents, > then that means I'm looking at a many to many relationship. Earlier you wrote: class Doc(meta.Model): ... inspired_by = meta.ManyToManyField(Doc) Based on your comments above, I think you mean: This one Doc can have many other Docs which inspired it. That's a OneToMany relationship. This Doc, and many others, can inspire other Docs -- that's not part of either relationship above. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Form field
On Sat, Mar 25, 2006 at 11:15:17PM +0800, limodou wrote: > On 3/25/06, PythonistL <[EMAIL PROTECTED]> wrote: > > Is it possible to have a field in a form that a user can not edit? > > I think django doesn't support these input attribute, so you should > extend the code or write the html code manually, just like: Don't forget that just changing the html code has nothing to do with properly securing your application --- you've got to make sure in the view code that an attacker can't bypass the html and try to submit new contents for those input variables. Validation of user input ***MUST*** always be done on the server-side and not JUST in the html code / javascript at the browser!! -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ASCII or PDF version of docs?
On Fri, Mar 24, 2006 at 07:45:18PM -0600, James Bennett wrote: > Every time you download Django, you get a complete copy of the latest > version of the documentation, in ASCII format. As I've noted on one of the doc pages on the web, that's not quite correct... You don't get all of the model examples -- and some of the needed documentation is in the example pages surrounding the actual examples. i.e. you don't get any of the doc at http://www.djangoproject.com/documentation/models/ It would be a good thing to get ALL of the documentation, preferably in both html and text (there's just so much meta data on the web site... links, bold, example text) that makes up the documentation (not just most of it) into the tar file you download. PDF in addition would be much appreciated too... I found it easier to printout the text docs and read chunks here and there, mark it up, etc. The ascii text-only doc files missed a lot of important meta data that a PDF would have helped dramatically. -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: magick-removal: Suggestion
On Mon, Mar 20, 2006 at 08:57:53PM +0100, Viktor Kerkez wrote: > Ok, I still think that its conceptually wrong to have two completely > different sorts of objects shareing the same name... As a friend of mine reminded me, part of your perception feeding that conception is that you're still thinking of these as being columns in a table... when in fact they are classes derived from FormField (and you can derive your own classes from FormField or even from other field types). So, you need to change your perspective to think of these as being objects, in an object-oriented sense, that happen to map onto tables and columns, rather than as columns and tables that happen to map onto field names. -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to get vote total in poll tutorial
On Fri, Mar 17, 2006 at 10:57:14PM -0800, [EMAIL PROTECTED] wrote: > No, one underscore doesn't work: > choices.get_values(fields=['poll', 'votes'], poll_id=1) > returns > TypeError: got unexpected keyword argument 'poll_id' > > I'm using two underscores because that's my (limited) understanding of > the field__lookuptype syntax of the API documentation > (http://www.djangoproject.com/documentation/db_api/#field-lookups) . > Specifically, I'm trying to get all the votes of the poll with the id > of 1. Then you probably want it to read: choices.get_values(fields=['poll', 'votes'], poll_id__exact=1) i.e. your "field" is "poll_id" and the lookuptype is "exact" which translates to "poll_id__exact", and THEN the equals sign and what value you are asking it to match. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Question about _pre_save
I had wanted to make up a unique field combining some other field and, ideally, an autoincrementing number unique to this class... I'd love to make this the primarykey, but I can't make up a SlugField as the primary key and another field to be the autoincrementing number because AutoField is only valid for the primary key. So I decided to make up a SlugField as just a unique field (with "id" as normal) and then I planned to populate the slug myself from some-other field AND "id" in the _pre_save routine. (since it seemed that prepopulate happened only in the admin interface and I needed it to happen all the time) Although the docs say that _pre_save "is called just before an object is saved to the database", that's not quite correct. _pre_save is called long before the db is committed, and BEFORE the AutoField "id" is set meaning that when _pre_save runs, id is null. So this leads me to several questions: Why not allow any integer fields to be autoincrementing (oops, that may be basic sql ... I haven't checked)? How else can I get a field to be a class-unique autoincrementing value? Why have _pre_save hook in before the autoincrementing fields get computed? Shouldn't _pre_save happen after the auto fields are set so that you can write code to USE the computed "id"? Thanks -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
subclass calling parent's _pre_save?
I found that a subclass' _pre_save method superceeds it's parent's and I have a situation where I need it to do something in addition to what it's parent does. e.g. class One(model): def _pre_save: ...something... class Two(One): def _pre_save: ? Based on Python docs, I've tried... with no luck: One._pre_save one._pre_save meta.Model.One._pre_save Model.One._pre_save In a subclass' _pre_save method how do I invoke it's parent's _pre_save method? Thanks -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
__repr__ and {% debug %}
As part of developing my first Django app I'd make use of {% debug %}
often to see what's happening. I spent a while yesterday trying to
figure out why, just inserting a debug line in my template caused a
traceback of a rendering exception.
Turns out that I mistakenly had created a class with a __repr__ that
returned a integer field instead of a "str". When I changed it to
"return str(self.value)" debug again worked fine.
I don't know if I'd call this a bug or not, but... I sure wish that
using a debug wouldn't protect itself from exceptions...
Yes, the docs do say:
Thus, you should always return a nice, human-readable string for
the object's __repr__.
I just don't think that debug should barf if an oject's
__repr__ doesn't return a string.
--
Glenn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
another template question
In my first Django app I've got the following "rough" model (not
real code, but enough to show what I mean):
class Rateable
some stuff common to all "Rateable" objects
class Rating
who = ForeignKey(User)
what = ForeignKey(Rateable)
values = ...
class People(Rateable)
class Place(Rateable)
and several other classes
In my templates, I'd like to be able to (for example):
Given an "object_list" of rateable things, I'd like to
then get the "Rating" valules for the current user.
I'm trying to figure out a good way to do this.
I don't see any way in a template to pass an argument
to a method. i.e. I can do
{{ object.get_rating_list }}
but I can't (that I can see) do
{{ object.get_rating_list(who__id={{ user }}) }}
(or something like it
I also don't see a way to write a method in the
model to get the then current user.
So, I've started to write a templatetag to do this,
but am wondering if there's a "better" way.
I'm starting to implement my own tag like:
{% this-rating thisone object %}
to set the variable "thisone" to the Rating of "object" for the
current user.
Is there a better way? What am I missing?
--
Glenn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: why is my view for a submitted form not getting a POST?
On Thu, Mar 09, 2006 at 11:21:38PM +0800, limodou wrote: > Please check this document http://code.djangoproject.com/wiki/NewbieMistakes > It seems that you lost a '/' after action name "rated". Whoa! Thanks!!!That did it! I never even thought of that because my url pattern had a "rated/$" and it got to my view... AND the documentation on forms shows an action with no trailing slash for "create_form" so I never thought that a trailing slash was needed. see http://www.djangoproject.com/documentation/forms/ in the finished version of the "create_form" template it uses "action="." with no trailing slash. So, why is it that action="." as in the documentation with no trailing slash is ok but action="rated" isn't ok? Is "." a special case (if so, then why use that in the documentation as the example of how to do a change_form), or is the finished version of the change_form wrong? -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
why is my view for a submitted form not getting a POST?
I've taken a working template and a working detail view and added
a form to that template AND another view to handle that form when
submit gets clicked.
In my template I've got:
Rating:
and that view's code is:
def place_rated(request, app_label, module_name, object_id=None,
template_name=None):
foo = foobar
try:
s = places.get_object(id__exact=object_id, select_related=True)
except:
raise Http404
# we either have a rating already or have to create one
rating = 0
if request.POST:
foo = foo
# this will actually do some other stuff, but... for example...
s.rating = request.POST['rating']
s.save()
foo = bar
return HttpResponseRedirect("/place/%s/" % object_id)
When I clicked on the form it got to that view just fine, but never seemed to do
anything, so... I added the "foo=..." lines purposely for debugging to throw an
exception
to see what was happening.
I added the "foo = foobar" line because it never got to the "foo = foo" line
(i.e. never got to the "if request.POST").
it barfs on the foo = bar line and the debug info shows:
Request Method: GET
...
GETNo GET data
POST No POST data
I thought that clicking on the SUBMIT button would be a post method
and that request.POST would be true (and POST would be
populated)... but it's not. Because it gets an exception at the
"foo=..." line, I know that it is getting to that view when I click
submit.
Huh? ? What's happening? What am I doing wrong? ?
p.s. although it never gets to the line "... request.POST['rating']",
is that the right way to write it to pull the input field named "rating"
out of the POST data?
--
Glenn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
templates invoking methods that need an argument?
Some sample code excerpts, before my question:
(this code is incomplete, but should give the idea of where I'm headed)
class Rateable(meta.Model):
value = meta.IntegerField()
def current_rating(self):
try:
r = self.get_ratee_list()
except:
return "None"
n = sum = 0
for rr in r:
n = n + 1
sum = sum + rr.value
if n == 0:
return "None"
return sum/n
class Rating(meta.Model):
value = meta.IntegerField()
ratee = meta.ForeignKey(Rateable)
rater = meta.ForeignKey(User)
class Place(Rateable):
class Thing(Rateable):
Now, I've easily writen templates that show Places or Things and that
show the ratings for each using {{ object.current_rating }} (as
appropriate, of course). But, I'm trying to figure out how to write a
template that would (a) show the rating for this object for user X or
(b) show the rating for this object for the current user.
I can think of a couple of ways to approach this problem, but I don't
know which path is "better"... I could write a custom template tag
that takes "user" as an argument; or I could try to see how else to
pass an argument or a context variable back to a class' method. Or,
perhaps I'm way off base and neither of these paths is right and
there's a much better way to attack this.
I'd appreciate some guidance on how to approach this problem...
Thanks
--
Glenn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
admin interface with subclasses
I'm working on adding "user ratings" to my first Django web app.
I'm having trouble getting the admin interface to work with
subclasses.
When I try the following it seems to work... up to a point. In a sh
script I create the db and populate with a couple of "places". Then, in
admin, when I click on Add Rating it shows a page with (as expected):
rateable (empty selection list), rating, and user (my logged in user
since I did createsuperuser and logged in for admin).
Then, when I click on the "plus sign" of "Rateable:" it goes off to
.../rateables/add/ and gives the following error:
IndexError at /admin/myapp/rateables/add/
list index out of range
Request Method: GET
Request URL: http://127.0.0.1:8000/admin/myapp/rateables/add/
Exception Type: IndexError
Exception Value: list index out of range
Exception Location:
... Django-0.91-py2.4.egg/django/contrib/admin/views/main.py in __init__,
line 359
Well, I don't have any "Rateable" objects... I've got two "Place"
objects which were created via a "Place" class subclassed from
"Rateable". I'd think that I somehow have to get it to do
.../places/add/ instead, but I don't see how to do that or the admin
interface doesn't work completely / correctly for subclasses. When I
try, in admin, to go to one of those "places" or try to add a new
place, it doesn't give me the option of seeing or adding a "Rating".
?
Below is the the model I was using...
--
Glenn
class Rateable(meta.Model):
rating = meta.IntegerField( null=True, editable=False,
help_text = "computed rating of this one thing", core=True)
def __repr__(self):
return self.rating
class META:
admin = meta.Admin(
list_display=("rating", "get_rating", ),
)
class Rating(meta.Model):
ratee = meta.ForeignKey(Rateable, core=True, null=True,
edit_inline=meta.TABULAR,)
rating = meta.IntegerField( null=True, editable=True,
help_text = "this person's rating of this one thing", core=True)
rater = meta.ForeignKey(User, edit_inline=meta.TABULAR,)
class META:
admin = meta.Admin(
list_display=("rater", "rating", "ratee", ),
)
class Place(Rateable):
title = meta.CharField('Title', maxlength=50, core=True)
description = meta.TextField('Description',
help_text='Short summary of this place',
blank=True,
)
city=meta.CharField(maxlength=50)
state=meta.USStateField()
address=meta.TextField(blank=True)
when_created=meta.DateTimeField(auto_now_add=True)
def __repr__(self):
return self.title
class META:
admin = meta.Admin(
list_display=("title", "description", "city", "state",)
,
list_filter=("title", "description", "city", "state",) ,
search_fields=("title", "description", "city", "state"),
)
def get_absolute_url(self):
return "/place/%i/" % self.id
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
not about Django, but about this list
Does anyone have any idea why a couple of messages (such as the one I'm including below) from a couple of different people have several lines combined making it very tough to read Or, more to the point, what can be done about this? Thanks -- Glenn On Fri, Mar 03, 2006 at 06:36:43PM -0500, Tom Tobin wrote: > On 3/3/06, wizeman <[EMAIL PROTECTED]> wrote:>> Hi. I'm just starting to use > Django and I'm loving it.>> Don't you think it would be great if Django was > ported to Boo (> http://boo.codehaus.org/ ) ? > Err, knock yourself out porting it if you want (as it's BSD licensedafter > all), but I don't think you'll see many of us jumping to switchfrom Python > anytime soon. ;-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: thoughts about adding a user rating
On Fri, Mar 03, 2006 at 04:50:37PM -0600, James Bennett wrote: > If it were an up-or-down, the ratings fields probably wouldn't be > PositiveSmallintegerFields, and the comments module's > get_rating_options method probably wouldn't use a 1-10 rating scale as > the example in its docstring ;) :-) Ahhh... I see... For some reason, the first comments/ file I looked at happened to be karma.py which has only an up/down rating. THEN I saw the other ratings... which I've been looking at between my previous message and your message. Thanks > Documentation of the comment app was another thing that was supposed > to happen a while back, and would be another great > LittleEasyImprovement... I'm making a list. Please Please Please do... some doc on comments would be VERY helpful -- some example templates (complete set of templates) would be nice too! I haven't yet seen how to integrate / use those ratings, but I do see those fields. On comments... I find that having free_comments and "just" comments quite confusing. I'd like to just have comments that can be either entered by a logged in user or, if my view allows it, by any anonymous user... at least, it SEEMS that's the difference between the free and "regular" comments. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: thoughts about adding a user rating
On Fri, Mar 03, 2006 at 03:02:32PM -0600, James Bennett wrote: > Take a look at the comments app distributed with Django > (django.contrib.comments), which has a rating system built in to it. Thanks, but it seems to me that it does a user voting (one up, or one down) rather than "I give this a 3 star rating". This voting scheme generates an int value that can easily be ordered_by, but I don't think it's a user-friendly as, e.g., a five star rating. I'm looking for a scheme by which each user can rate each thing on, e.g., a scale of 1-5 stars and then be able to say "show me the top ten user rated things", and when displaying each thing to show the current average number of stars for that thing. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
thoughts about adding a user rating
A site I'm developing could greatly benefit by having a user rating added to it... e.g. a 1-5 star rating for each post and then being able to display the top ten posts (perhaps additionally such as top ten added this week, or top ten on subject X, etc.) or other such "user scoring" uses. Before I go off trying to do this (while I'm still learning Django), I thought that this must be a fairly common thing to have done and, not wanting to reinvent the wheel, I wonder if anyone could point me to an existing example code for this. Or, ideas/thoughts/comments gladly accepted on how to structure the models and views-code for this. Thanks -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: db_api with a table with multiple relations
On Thu, Mar 02, 2006 at 10:03:52AM +0800, Russell Keith-Magee wrote: > a.reporter_id = r2.id Wow, thanks! As I said, I had tried "... = r2.id" but that didn't work. I never would have thought of "a.reporter_id" since in the code to create it it uses "reporter=...". Do you know if in the M-R version that will also still work? Or will I have to convert it to what I had tried but hadn't worked? -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: db_api with a table with multiple relations
On Mon, Feb 27, 2006 at 11:18:48AM -0800, Glenn Tenney wrote: > I knew how to add a record with a many_to_one, but for when I > needed to change that relation afterwards, my testing showed > that just changing the value (e.g. article.reporter=new_r.id) > didn't actually change the relationship -- and a.get_reporter_list > still returned it in the set as it was when originally added. > ... > Was there something wrong in my tests? How are you supposed > to change a many_to_one relationship AFTER you've successfully > set one up I've repeated my tests and the rough code below still doesn't work... (ok, it's with my project, but I've converted it to match the reporter / article models as from http://www.djangoproject.com/documentation/models/many_to_one/ ) and, assuming that in my Python 'reload-my-db.py' script I've created and saved reporter r1 and r2... a = articles.Article(id=None, headline="This is a test", pub_date=datetime(2005, 7, 27), reporter=r1) a.save() print "count now 1", r1.get_article_count(), "\n" # shows it was 1 print "count now 2", r2.get_article_count(), "\n" # shows it was 0 # I want to change the relationship of article "a" to be # to reporter "r2" instead of "r1" without having to # delete and re-insert that record. So I tried... a.reporter=r2 a.save() # I also tried a.reporter=r2.id with the same results print "count after 1", r1.get_article_count(), "\n" # shows it was 1 print "count after 2", r2.get_article_count(), "\n" # shows it was 0 If I go into admin, it still shows a.reporter to be r1 and if I change it to r2 in the admin, everything then seems to be fine. My question: What is the correct way to change a "ForeignKey" field's relationship? What am I missing? Thanks -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: db_api with a table with multiple relations
On Mon, Feb 27, 2006 at 10:24:33AM -0800, hsitz wrote: > Glenn -- I think your one to many answer is here: > http://www.djangoproject.com/documentation/models/many_to_one/ I knew how to add a record with a many_to_one, but for when I needed to change that relation afterwards, my testing showed that just changing the value (e.g. article.reporter=new_r.id) didn't actually change the relationship -- and a.get_reporter_list still returned it in the set as it was when originally added. I thought, then, that there must be something like set_FOO for many_to_one relationships... or something. Was there something wrong in my tests? How are you supposed to change a many_to_one relationship AFTER you've successfully set one up -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: db_api with a table with multiple relations
At 6:22 PM -0800 2/26/06, hsitz wrote: >Have you taken a look at the Many-to-many relationships example? Looks >like you're trying to manually create the links between tables, whereas >you're supposed to use the Model API's built-in 'set_x' method. > >http://www.djangoproject.com/documentation/models/many_to_many/ Wow, thanks a lot! Just what I needed! One problem I foresee, though, is that I also have some many_to_one fields. Many_to_one fields do not have a set_FOO method. Since I might need to change the relationship of such a field after the record is created, how do I do that? Notes to the documentation maintainers: 1) I looked through the db_api documentation and this wasn't in there -- I think it should be there. 2) I didn't expect something called "examples" to contain documentation per se, but rather more just sample code. Something like that many_to_many "example" needs to be called "documentation' and not an example. Feature suggestion: With all of the get_FOO_this and set_FOO_that methods etc., it sure would be nice to have some tool akin to "django-admin.py sqlall " that would show me all of the possible methods for this model. It would help, for example, knowing that set_FOOs (a) gets the "s" appended to it or not, and (b) that there isn't one for FOOBAR because FOOBAR is a many_to_one and not a many_to_many. Thanks again. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Template IF statement with <,>,<=,>= (or equvalent)
On Mon, Feb 27, 2006 at 01:42:23PM +0300, Ivan Sagalaev wrote: > Putting values in columns is indeed presentation logic. But deciding > what exactly is "debit" or "credit" is a business one. Django templates > pretty much require you to supply this exact distinction without > "implementation details" (<0, >=0) even if these details are so small > and obvious. I was thinking about this too... in my case I've got an event starting date and ending date; in my views I want to be able to view based on criteria such as: hasn't happened yet, hasn't happened yet but will happen sometime this month / quarter / year, happened already this month/quarter/year. That sounds like a view criteria to me... What approach would you suggest taking in a case like the one I've just described above? Thanks. -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
db_api with a table with multiple relations
I'm trying to figure out how to manually create entries in a database where one table has multiple fields related to other tables. What I've tried to do does create the tables ... partially. Because there are other hidden "relationship" tables, I'm not sure how I'm supposed to populate those other tables. This question is a bit hard to explain, so let me try with the following very rough example (rough and not totally correct code!). class A class B class C a=meta.ForeignKey(A) b=meta.ManyToManyField(B) In my code I do (again, VERY roughly!) p=app.A() # to create an A p.save() q=app.B() # to create a B q.save() and then r=app.C() # to create a C r.a = p.id # to relate to the A r.b = q.id # and to realte to the B r.save() The problem is, if I later do something with A's or B's get_c_list() or get_c_count(), they're not there. The standard add_foo() only would seem to work when there's one relation -- or at least, I didn't try it when there are multiple relations... So, what's the "Django Way" to do this? Whew... I hope that was clear enough... -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Naming conventions in docs / tutorials
On Sat, Feb 25, 2006 at 06:18:20PM +, Luke Plant wrote: > 'Site' in that example was a model in my own app -- there is a Django > model of the same name, but I don't know that much about it. As I've been learning Django this past week, this type of naming issue has bitten me over and over and over. As a major change (magic-removal) is underway, now's the time to also go back through the documentation... I beg everyone doing documentation / tutorials to come up with some absolutely clear naming conventions -- that will make it crystal clear to people which substrings in a name are what. e.g. if I see "polls.Polls", which word is my app name or my module name or a model class name etc. There might have to be one "form" for documentation and another "form" for working code examples. e.g. for me, I find a string such as "/_get" to be crystal clear in documentation. Equally, I would find "APP_LABEL_MYPROJECT/MODULE_NAME_POLLS_get" to also work, but not be as crystal clear. -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django versions
On Fri, Feb 24, 2006 at 01:04:31PM -, ChaosKCW wrote: > So if your starting from scratch like > me, and your willilng to put up with a few bugs, the magic removal is > the way to go. The problem I see with the m-r path for a newbie is that all the docs, tutorials, and examples are pre-m-r ... so starting from scratch with the m-r means a lot more headaches in learning Django. -- Glenn Tenney --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: generic views - object_detail and info_dict
On Tue, Feb 21, 2006 at 09:22:25PM -, Jan Rademaker wrote: > The 'archive_day' you see in urlpatterns is the name of the view, eg. > django.views.generic.date_based.archive_day and not some string that's > appended to the module's name. Thanks... for some reason, I had the perception that the urlpatterns specified the template not the view. Knowing it's the view I went to the source code and now understand. It's amazing how one reads things when you have an incorrect perception to begin with :-) Perhaps that might need to be more clear in the docs? > The default template names for date > based views happen to be the same as the name of the corresponding > view. The default template name for the object_detail view is > _detail, so in this case entries_detail. > > See > http://www.djangoproject.com/documentation/generic_views/#using-date-based-generic-views Except that it's not IN the docs... :-) At least, searching for "_detail" did not show any such explanation. The docs for archive_ all have a line like: "Uses the template app_label/module_name_archive_day by default." but the description of object_detail (for both date_based and list_based) does not have anything to say how the template name is derived. On a related note... I find it a bit confusing to see something like "module_name_archive_day" to mean (in my syntax) "_archive_day" (i.e. the contents of the variable named "module_name" will be followed by the string "_archive_day"). What with so many things taking 'variables' and strings and combining them, I would suggest SOME demarcation in the docs when using the name of a variable in a string along with other characters. For me, placing a variable name between <...> is clear since that doesn't show up as real text, but something is really needed for clarity. In part, this did add to my misunderstandings. -- Glenn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
generic views - object_detail and info_dict
After the tutorials I was looking over the source code for the djangoproject.com
site.
(1) in djangoproject.com/apps/blog/urls/blog.py I see:
from django.conf.urls.defaults import *
info_dict = {
'app_label': 'blog',
'module_name': 'entries',
'date_field': 'pub_date',
}
urlpatterns = patterns('django.views.generic.date_based',
(r'^(?P\d{4})/(?P[a-z]{3})/(?P\w{1,2})/(?P\w+)/$',
'object_detail', dict(info_dict,
slug_field='slug')),
(r'^(?P\d{4})/(?P[a-z]{3})/(?P\w{1,2})/$', 'archive_day',
info_dict),
(r'^(?P\d{4})/(?P[a-z]{3})/$', 'archive_month', info_dict),
(r'^(?P\d{4})/$', 'archive_year', info_dict),
(r'^/?$', 'archive_index', info_dict),
)
(2) And in djangoproject.com/templates/blog/ are the files:
entries_archive.htmlentries_archive_month.html
entries_detail.html
entries_archive_day.htmlentries_archive_year.html
I see how "archive_day" (or month or year) gets converted to
"entries_archive_day", but I have no clue how / why / when
"object_detail" gets converted to "entries_detail". For consistency I
would expect to see just "detail" in urlpatterns and THAT gets the
module_name prepended, but I don't see how the "object" part gets
dropped but the "archive" part doesn't. ???
--
Glenn
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
