Re: Pluggable QA app?
baxter gretschpages.com gmail.com> writes: > > Can anyone give me any suggestions for a relatively simple, pluggable > Q app? I'm looking for something sorta Stack-Overflow-ish, but I'm > OK with handling voting, authentication, search, etc. separately. > > What I've found so far (OSQA, Askbot, soclone) are far from pluggable. > I don't want a whole other site, just an app. Django-Voice came up somewhat recently on the Django Community feed, and at least from screenshots seems very nice: http://django-voice.googlecode.com/ Haven't had an excuse to try it myself, but it might be what you are looking for. -- --Max Battcher-- http://worldmaker.net -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: State of the Django MPTT Art?
Jon Loeliger wrote: Folks, I'd like to add a few MPTT manged data-sets to my projects so I am wondering what the current state of the MPTT art is. I'm using Danjgo 1.1.1 right now, and would like to slap down an MPTT manager in my project that is BSD-ish licensed, allows multiple, different sets of nodes, and hopefully comes with a good admin interface too! Googling shows both django-mptt and -treebeard, but are there good recommendations pro- or con- for either one? Or is there a better third choice out there now? They both seem quite strong and useful. I think Treebeard edges out django-mptt for the fact that it provides a few other managers for tree storage besides MPTT. It makes it pretty easy to use the same methods to browse/query trees no matter which method they are stored in the database. (Plus you can switch between them relatively easily as your storage needs change.) I think its documentation does a pretty good job describing the trade-offs between the various storage methods it supports, and certainly the best form depends on the data being stored. -- --Max Battcher-- http://worldmaker.net -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: DateTimeField arithmetic problem
Continuation wrote: > if form.is_valid(): > object = form.save(commit=False) > delta = datetime.timedelta(days=object.days_difference) > object.end = object.start + delta > object.save() > > But I got the error: > type object 'datetime.datetime' has no attribute 'timedelta' This sounds like a silly import error... It sounds like you've got something like: from datetime import datetime Where you really want just: import datetime (Because datetime.datetime.timedelta doesn't exist, but datetime.timedelta does.) -- --Max Battcher-- http://worldmaker.net -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Sick of defining urls
Todd Blanchard wrote:
> settings.py has a list of applications to include (INSTALLED_APPS).
> Fine. But then, in urls.py I have to repeat myself by importing each
> application's urls.py to add them. (r'^admin/', include(admin.urls)),
>
> And then I have to fiddle the template path so the templates in the
> application are found or create a symbolic link from my templates root
> folder to the templates folder in the app.
If you have the app template loader
('django.template.loaders.app_directories.load_template_source')
correctly under TEMPLATE_LOADERS, most apps' templates should just work.
No template path fiddling or symlinks necessary. Throw in the egg loader
if you are using apps in eggs; write your own loader for custom needs;
etc...
--
--Max Battcher--
http://worldmaker.net
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: domains vs sub-domains
Chris wrote: > I've recently been in discussion about which is better to have. > > http://media.example.com OR > http://example.com/media/ > ... > Which method should I adopt? I personally like the second method, but > if it will effect performance/ loading times at all then I should go > with the first method. I will be serving things like media and API's > on a separate server or instance. Any thoughts? All things considered the choice here is probably more aesthetic (which looks "prettier" to you) than about performance. If you like the second, then go with the second. If performance is an issue and you think the first gives you better performance you can edit your HTML templates and switch... Personally I like the first because it is "prettier" to me. It is also much easier for "poor man's load balancing"... If one server gets to crowded on the very basic sites that I host, I can swap it to another server with "merely" a DNS change. But that is only but one load balancing technique among many... Another reason I use subdomains, particularly for media, is the ability to use "off-the-shelf cloud products". For instance, my media.worldmaker.net "server" is currently a CNAME for a 'cheap' Amazon S3 bucket. It could just as easily be on Rackspace CloudFiles, for all that it matters. Meanwhile, I'm also considering "upgrading" it to a CloudFront distribution, potentially without having to touch any of my HTML for "instant" bonus performance. Having all my static media hosted by good static media hosts saves me time to think about my dynamic content and tools. Your mileage may certainly vary. -- --Max Battcher-- http://worldmaker.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: tag counts
dk wrote: > I am making a site to contain "examples" that may be tagged with > "tags". I am wondering how to count the uses of the tags (for making > a tag cloud, for example). Your best bet for tags is to use django-tagging: http://django-tagging.googlecode.com/ That app provides just about everything one needs for tagging, including template filters for tag clouds. -- --Max Battcher-- http://worldmaker.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Marking usernames as not for use dynamically
> Not really answering your question, but a couple simple workarounds: > > - put your user profiles under http://domain.com/profiles/username I'm rather fond of using URLs of the form: http://example.com/~username/ It's an old tradition (well, old in internet/unix years), but I think sometimes the tilde as a sign of a user page is forgotten/under-rated in modern URL planning. -- --Max Battcher-- http://worldmaker.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to get a queryset?
adelaide_mike wrote:
> Hi
> My models are, essentially :
> class Cable(models.Model):
> cable = models.CharField(max_length=8)
>
> class Connector(models.Model):
> connector = models.CharField(max_length=8)
>
> class Node(models.Model):
> cable = models.ForeignKey(Cable)
> connector = models ForeignKey(Connector)
>
> So, a real world cable can be plugged in to no, one, or two connectors
> (one at each end). The Node table describes the junctions between
> cables and connectors.
>
> Can I, without resorting to raw SQL, build a queryset that shows
> connector-cable-connector?
You would have a hard time even accomplishing that in raw SQL with those
models... If you have the flexibility to change your models I would try
something like:
class Connector(models.Model):
name = models.CharField(max_length=8)
class Cable(models.Model):
name = models.CharField(max_length-8)
left_connector = models.ForeignKey(Connector, blank=True, null=True)
right_connector = models.ForeignKey(Connector, blank=True, null=True)
This makes your 0, 1, or 2 relationship explicit. I went with the
left/right distinction as it is an easy "handed" way of describing them,
but other choices may be more appropriate depending on your usage
patterns...
Otherwise, your best bet would seem to me to be to use
Node.objects.all().orderby('cable') and group the
connector-cable-connector by yourself. Something that I generally find
useful in situations like that is Python's groupby function from itertools.
--
--Max Battcher--
http://worldmaker.net
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Django with Cherokee web server
Rudy Lattae wrote: > * Have you used Cherokee with Django? I swapped a VPS a few months back from Apache + mod_python to lighttpd (FCGI) then to nginx then to Cherokee (SCGI)... I got somewhat frustrated with configuration editing and ugly/useless wiki documentation, so ultimately the deciding factors for me were Cherokee's well-formatted, easy to read (up to date!) documentation and the cherokee-admin tool. The cherokee-admin is often especially handy because I tend to run little experiments in random sub-domains and you can make updates/changes on the fly, tweaking things until they work right. > * Have you run any benchmarks comparing (or noticed performance > differences between) Cherokee and Apache + mod_wsgi/mod_python -- esp. > for concurrent requests? I haven't run any benchmarks. Anecdotally the speed has never been an issue for me, I've generally been more worried about RAM usage (because these are VPSes I'm using), and all of the FCGI/SCGI solutions I've used seem to be about what I needed to better deal with that (particularly for the sorts of sub-domains that don't get hit all that often). > * Are there any issues, concerns, road blocks that one needs to > lookout for when using Cherokee to serve a Django site/app/service? I've been happy with it. The Cherokee documentation appears to tell you everything you need to know, clearly and concisely. I haven't had any problems with it (knock on wood), and its been running stably for a few months now without the need for any further configuration tweaks or resets. -- --Max Battcher-- http://worldmaker.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
ANN: Agoranomos (7.12.11)
I'm not sure how much interest there will be in this, but I was figuring that maybe someone might have a good use for this, and I don't know of any existing applications out there for this. I built a simple Django-based Auction application for a class final project. It's specifically intended for use for small communities and charity auctions. I named it Agoranomos, which is Greek for "market overseer" and is also sometimes used as a title for public benefactor. It's very spartan and the templates included as examples are ugly ones based on my personal site templates. There's no payment processing of any sort here. The biggest bell/whistle is that I included a couple of Ajax views and the JavaScript application for Ext 2.0 (extjs.com) to use with them. The current license for the code it GPL 2.0... I have a small demo site up right now (please be gentle, this is my personal site and I know it doesn't take much of a pounding): http://agora.worldmaker.net/ I have a simple issue and patch tracker set up: http://agora.code.worldmaker.net/ You can grab the source code with Darcs easily enough (this is S3, so less worries about beating it up, more worries about my wallet): darcs get http://repos.worldmaker.net/agora/main/ For additional convenience, here's a compressed archive of the code to date: http://repos.worldmaker.net/releases/agora/7.12.11.zip Let me know if you find any good uses for this code. If you build the next eBay with it, I'd love a small cut. ;) -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: ValidationErrors
Todd O'Bryan wrote:
> How do people handle validation errors in a standard way? Surely, the
>
> {% if form.name.errors %}*** {{ form.name.errors|join:", " }}{% endif %}
>
> repeated over and over again (with field changes) in the documentation
> example cries out for some better way.
>
> I was thinking of creating a custom tag, but thought I'd ask to make
> sure I wasn't missing something.
{{ form.name.html_error_list }}, wraps it in a
--
--Max Battcher--
http://www.worldmaker.net/
"I'm gonna win, trust in me / I have come to save this world / and in
the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
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: nested for and ManyToMany field problem - MySQL
Adam Hoscilo wrote:
> I get this error: len() of unsized object
> while doing nested for loops in the template:
> {% for entry in object_list %}
> {% for category in entry.categories %}
> {{ category.name }}
> {% endfor %}
> {{ entry.get_absolute_url }}
> {% endfor %}
>
> entry.categries is ManyToManyField
Then you want entry.categories.all in your template.
--
--Max Battcher--
http://www.worldmaker.net/
"I'm gonna win, trust in me / I have come to save this world / and in
the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
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: POST to view loses POST data
Jeremy Dunck wrote: > On 6/17/06, Luke Plant <[EMAIL PROTECTED]> wrote: >> Long version: >> request.POST is (essentially) a dictionary of post variables. As such, >> if it is empty, it evaluates to False, even if the request method is >> 'POST'. In your form, you don't have a single 'successful' field -- >> the only field is an , and since it doesn't have a 'name' it >> can't be successful. > > A post is a post w/ or w/o successful controls. How about putting a > dummy into the dictionary to force true? > > Yeah, this is kludgy, but the alternative is to put in a attribute on > the request object to say "is this a post?" or force people to fix > "bugs" in their valid HTML. :) That's what request.META["REQUEST_METHOD"] is for. http://www.djangoproject.com/documentation/request_response/ -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: I think I'm doing something wrong...
Elver Loho wrote: > Sadly it seems you, along with so many, many others, have fallen into the easiest problem in the book. Your action address should have a following /. http://code.djangoproject.com/wiki/NewbieMistakes#POSTtoviewslosesPOSTdata -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Unhappy, reinventing
Elver Loho wrote: > http://elver.cellosoft.com/2006/05/24/acceptable-use-of-programming-in-templates/ The XML in Python trick is somewhat similar to how Django's syndication (RSS/Atom) framework works, and it is great for such structured XML documents. On the other hand, HTML is a weird thing and not something that I'd want to build with the DOM approach. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: save() called 2 times.
Jeremy Dunck wrote: > On 5/5/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > ... > #Addedamorepowerfulwayofoverridingmodelmethodsremovedhardcoded_pre_save_post_saveetc. You can thank Trac for that. Apparently somebody forgot to tell them that it might be a good idea to truncate after so many characters just so that URLs don't get out of hand... not to mention all the wasted characters sent in your HTTP responses and emails mentioning unrealistically long URLs. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: ATTENTION: magic-removal being merged to trunk TODAY
Adrian Holovaty wrote: > Attention all users of the Django development version (a.k.a. trunk)! > > We are merging the magic-removal branch to trunk this evening, Monday, May 1. > > Do not "svn update" your Django code unless you're ready to convert > your code to magic-removal syntax. > > If you "svn update" by mistake and aren't yet ready for the > magic-removal APIs, you'll be able to "svn switch" back to the last > version of pre-magic-removal Django, which will be tagged in > Subversion. svn update can take an optional revision number as an argument (IIRC, --rev=) and it will "de-update" (update your working copy to a previous revision). -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 can users only edit their own files?
layik wrote: > I am scared now Luke > > How am I going to avoid this? I sign out from Django but I still can > see this: > http://localhost:8000/admin/auth/users/4/ It was probably just a cached version of the page provided by your browser. Did you: Shift/Ctrl-Refresh (depends on browser/OS) the page? -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Pluggable User/Registration/Authentication App?
Esteban wrote: > I am pretty much fresh blood to Django and I am looking for a pluggable > application that will provide some sort of front end interface to > handle user registration and authentication to an existing project. > For many sites a user system is key, I have been reading around and > found the authentication model page: > > http://www.djangoproject.com/documentation/authentication/ > > However it would be great if there was some sort of pluggable > application that does the basics, like I said most developers/designers > would find this useful for their projects. So any ideas where to start > on this? Does anyone know if anyone has already made something like > this to build off of? There are several "generic" auth views: login, logout, password change, password reset. These can be found scattered across django.views in trunk/0.91 or in django.contrib.auth.views in M-R. These give you the action code and then you just need to write the templates for your site and wire the views somewhere in your urls. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: querying for an empty set in m-r?
Russell Cloran wrote: > Hi, > > On Tue, 2006-04-11 at 21:20 -0400, Max Battcher wrote: >> if sometag.article_set.count() == 0: >> pass # your code here > > This will test if one tag has an empty article_set. AFAICT, the question > is on how to find all tags which have an empty article_set. Yes, you > could do it this way, but it means querying the DB again for every tag. Oh, right. You could do: tags = [tag for tag in Tag.objects.all() if tag.article_set.count() == 0] n queries for n tags, but it is "pretty" Python. Doing db-cleanup shouldn't happen all that often, so you probably don't need the best performance, and I'd just stick with the list comprehension. Too bad there isn't some cool easy Python way to make a list comprehension/generators like that as Lazy as the Descriptors... Byte-code parsing, anyone? http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442447 -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: querying for an empty set in m-r?
if sometag.article_set.count() == 0: pass # your code here On 4/11/06, Brian Elliott <[EMAIL PROTECTED]> wrote: > > Suppose I have the following two model objects: > > class Tag(models.Model): > name = models.CharField(maxlength=10) > > class Article(models.Model): > tags = models.ManyToManyField(Tag) > > > Each Article can be associated with multiple Tags and vice versa. > How can I query the Tag model to obtain all Tags with no associated > articles? (m-r) I basically want to delete unused tags. > > Thanks, > Brian > > > > > -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 4/11/06, Glenn Tenney <[EMAIL PROTECTED]> wrote: > > 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. "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). I don't think it implies that you shouldn't raise an exception, after all raising an exception is valid Python code. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 time-zone chaos
On 4/11/06, Siah <[EMAIL PROTECTED]> wrote: > I had the same problem and chose to ignore it. I think it might be a > bug with Django. I've had so many headaches from time-zone related issues across multiple systems. Time-Zones are just inherently frustrating and when you are trying to syncronize time-zones across a scripting language (Python's datetime library), a database, and an operating system, it's obvious there are plenty of oppurtunities for things to become incorrect... Ultimately I wouldn't fault Django itself for it. One of my Django applications pulls data from an outside application, which in turn has its own ideas about Time-Zone... -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 4/11/06, Glenn Tenney <[EMAIL PROTECTED]> wrote: > > 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... You are free to raise your own exception in the path that fails to call super().delete() in M-R. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: post data always empty
[EMAIL PROTECTED] wrote: > I was wondering if somebody could help me out. i'm trying to write a > simple form to create users ... however the post data always seems to > be empty. > > Here's the template: > > http://code.djangoproject.com/wiki/NewbieMistakes#POSTtoviewslosesPOSTdata -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Column [Datefield] cannot be null
dave.l wrote: > I have a model as follows: > > class Building(meta.Model): > survey_date = meta.DateField(null=True) > check_date = meta.DateField(null=True, blank=True) > researcher = meta.ForeignKey(Researcher) > > > I was hoping that this would let me have a blank check_date (which > would be stored as null) but enforce entry of a survey_date. But from > my admin page if I enter a survey_date (but leave the check_date blank) > I get the following on Save: > > OperationalError at /admin/coils/buildings/add/ > (1048, "Column 'check_date' cannot be null") > Request Method: POST > Request URL: http://81.3.86.154:8000/admin/coils/buildings/add/ > Exception Type: OperationalError > Exception Value: (1048, "Column 'check_date' cannot be null") > Exception Location: > /usr/lib/python2.3/site-packages/MySQLdb/connections.py in > defaulterrorhandler, line 32 > > What have I missed? This is a constraint in the database that is complaining, which means that your table in the database is not the same as the Model you provided (most likely because you made the above change after an install/sync). -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: ImageField upload_to
timster wrote: > Should the super() method work even though I'm not using MR? No. super().save() only works in MR. You'll need the _pre_save() and _post_save() hooks in .91 or trunk. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: ImageField upload_to
timster wrote: > Should the super() method work even though I'm not using MR? No. super().save() only works in MR. You'll need the _pre_save() and _post_save() hooks in .91 or trunk. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: magic-removal - count with a condition
Istvan wrote: > In Django 0.91 the > > foos.get_count( complex=condition ) > > was a valid construct. The magic removal branch raises an exception: > "count() takes exactly 1 argument (2 given)" when doing a : > > foo.objects.count( condition ) > > Is that intended? What would be a workaround? foo.objects.exclude(somecondition).filter(othercondition).count() The lazyness of the new QuerySets means that the above simply creates a COUNT query, no matter how many exclude()s and filter()s you might combine. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 query roots in a model hierarchy
Malcolm Tredinnick wrote: > On Sat, 2006-04-01 at 00:11 -0800, shredwheat wrote: >> Using a hierarchy of models like the example shown on this cookbook >> page. How do you query for the root level objects? Can it be done with >> a single query? Or do I loop over and test on the Python side? >> >> http://code.djangoproject.com/wiki/CookBookCategoryDataModel > > The root categories are the things without parents. So construct a > filter that selects all the objects with a NULL parent_id field. In your get_list(...) or filter(...) (depending on Django version as appropriate), you have a parent_id__isnull=True as one of the arguments. (Note the double underscore before isnull and the single underscore before id.) -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: overriding User class
Don Arbow wrote: > > On Apr 1, 2006, at 2:14 AM, [EMAIL PROTECTED] wrote: > >> I'm wondering what is the way to achieve User overriding if I want, >> say, add >> a new field to the django User class? >> Is there a way to do that without modifying the django source code ? >> > > Have a look at this for one way to do it: > > http://code.djangoproject.com/wiki/ExtendedUserModel Another possibility is to create your own Model with a OneToOne relationship, or ForeignKey relationship, as appropriate, and then use lookups as necessary. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 3/30/06, ToddG <[EMAIL PROTECTED]> wrote: > > I'm not sure if this was earlier missed or ignored by people [nobody > explictly ruled it out], I can't help but think Django's URL handling > will either drift towards re-implementing Routes: > http://routes.groovie.org/ or staying as it is. (note the lastest > version has a nice feature where you can pass in a function to do > pre-processing or whatever you want to args and such before creating a > Route or matching it). 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". I would only suggest that renaming to perhaps get_canon_url() might be somewhat less confusing, in that it refers to a canonical URL rather than the preferred URL or every URL. (For example, my most common problem is the objects that have many different URLs in the same project based on semantic differences (ie, same object to admin, different object to user). In some cases get_absolute_url() points to the canonical URL that fits 85% of the cases and that view will do semantic redirects if necessary.) The ABSOLUTE_URL_OVERRIDES tool is a handy convenience to fix this seperation problem, and with it you can do all sorts of crazy things (thanks to the pythonic ability to pass around functions) like implement your own project-specific mini-routes or whatever (see my previous post on the subject). -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Custom templatetags are ignored. Why ?
ak wrote: > After a bit of research I found that my templatetags dir has > __init__.pyc file and it tells me that django tried to include this > directory but my news_tags.py file has no .pyc Sounds like you have a syntax error in news_tags.py. Try importing it within a Python shell. Basically: python manage.py shell >>> from myproject.myapp.templatetags import news_tags -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Mixing with Mailman?
On 3/26/06, shredwheat <[EMAIL PROTECTED]> wrote: > > I'm planning the development of a site that will have several > integreated mailing lists. I think Django and Mailman could be a good > mix for this. After some intitial browsing it doesn't look hard to > import the Mailman package and start querying/setting from Python. > > Has anyone travelled this road before? Are there any links of this > nature? I've thought about it, but I've not put any work into such a thing. I'm not sure I'd have the time, either. It's interesting in that the Mailman website TODO list for Mailman 3 requires almost a Django-like framework (decent db support, decent template engine). Near there it points to one similar attempt, a Zope-Mailman integration: http://www.zope.org/Members/srichter/Products/ZMailman Maybe that will offer some ideas/insight. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 3/28/06, pbx <[EMAIL PROTECTED]> wrote:
> I think rolling functionality similar to ABSOLUTE_URL_OVERRIDES into
> URLconfs is the way to go. As others have pointed out,
> get_absolute_url() doesn't cover enough ground and creates unnecessary
> coupling.
You realize that because ASOLUTE_URL_OVERRIDES takes arbitrary
functions you could do that today with no framework changes? (Might
be something worthy of an addition to the body of shortcuts, though,
if someone comes up with a decent version.)
Off the top of my head (don't blame me if it has bugs):
def urlfromconf(object, path):
urlconf = __import__(path)
return urlconf.absolute_url(object)
ABSOLUTE_URL_OVERRIDES = {
'myapp.somemodel': lamda o: urlfromconf(o, 'myapp.urls.somemodelrelated'),
}
Then in myapps.urls.somemodelrelated:
def absolute_url(object):
return "/path/to/object/%s/" % (object.id)
--
--Max Battcher--
http://www.worldmaker.net/
All progress is based upon a universal innate desire on the part of
every organism to live beyond its income. --Samuel Butler
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
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: choices
Todd O'Bryan wrote: > I'm an almost complete Python newbie, and I found dictionaries, but > is there an automatic way to deal with lists of pairs that have been > used for choices settings in the admin view, cause they're tuples of > tuples, right? > > I have > > KINDS = ((0, 'foo'), (1, 'bar')) > > class Thing(meta.Model): > kind = meta.IntegerField(choices=KINDS) > > I'd like to include the text values of kind in the object's __repr__ > method and in a table view, but can't figure out how. If you visit the Admin's documentation site (link in the top bar), under Models it will point you to the fact that Django magically creates a function for you to do just that. In your example this would be: something.get_kind_display() -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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?
> Anyway, am I overthinking this whole thing? Yes. The major pattern in Django is that your model objects should have a: def get_absolute_url(self): return "/bar/%s/" % (self.id) Then when you change the URL scheme you can either update your model objects, or in cases where there are multiple uses of your model objects (ie, two projects sharing an application), Django also provides, for your settings.py file, the ABSOLUTE_URL_OVERRIDES setting, which you can look up in the appropriate documentation. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Advice on using model to bulk/batch load database
DavidA wrote: > First, to use the model from a script I had to set the > DJANGO_SETTINGS_MODULE environment variable and add the base directory > to sys.path. I've seen this before so I guess this is just the way it > is but it would be nice not to have dependencies on environment > variables. Is there a different way to do this? You can set the environment variable at the top of your scripts by importing the Python os module, just like you can import sys and set sys.path. > Finally, for dates I had to manually convert them because they weren't > in the -mm-dd format required by DateField.html2python. It seems a > bit limited to only support one date format in DateField but I guess > that avoids the ambiguities with date formats. Since my model's fields > are the same names as the column headings in the flat files, now I can > map all the conversions automatically without doing anything > field-specific, *except* for date fields. Any suggestions? The Python datetime and time modules are huge resources. In this case you want time.strptime() to parse an arbitrary time format into a tuple and then you can use that tuple to create a datetime.date object which you can directly assign to the DateField. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 in magic removal
Arthur wrote:
> Hi all
>
> I'm trying to use generics on the magic removal trunc and I'm a bit at
> a loss because the queryset variable seems to get autoconverted to a
> string. The following urls.py always results in a "AttributeError:
> 'str' object has no attribute 'model'":
>
> from django.conf.urls.defaults import *
> from models import TodoItem
>
> info_dict = {
> 'queryset': TodoItem.objects.all()
> }
>
> urlpatterns = patterns(
> 'django.views.generic.list_detail',
> (r'(\d+)/$', 'object_detail'),
> )
>
Shouldn't that be:
urlpatterns = patterns(
'django.views.generic.list_detail',
(r'(\d+)/$', 'object_detail', info_dict),
)
Your example you aren't passing in that info_dict you created.
--
--Max Battcher--
http://www.worldmaker.net/
"I'm gonna win, trust in me / I have come to save this world / and in
the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
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
Viktor Kerkez wrote: > Glenn Tenney wrote: >> 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). > > I think you didn't understood me... Classes from django.forms are > derived from django.forms.FormField, but classes in > django.db.models.fields aren't. They are derived from > django.db.models.fields.Field, and they are conceptually different but > still haveing the same naming convention *Field... This is fairly common in various languages that you should always treat things in different namespaces (django.forms vs. django.db.models.fields), regardless of naming scheme, as being conceptually different. In most cases you should keep in mind that the entire namespace is just as much a part of the naming scheme as the class name itself. There's no reason to add verbosity to your class names that is already in your namespace name(s). -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: newbie question about admin module
mahakala wrote: > Hi, everybody > > I just created a simple data entry application in django, and I want to > use contrib admin as the data input interface and the admin user > management, I want the system log which staff user input the every > single line data. I know there is an action history. But I still want > there is a field in each record to log who create it and who last > change it. Is there a special model field can do this?or it must be > done through programming about auth module.? Thanks. In the options for a DateTimeField you can specify auto_now=True and the Admin will autofill it with the "current time" (which becomes the last modified date). There is no current way to do the same with User, but there is a proposed CurrentUserField in the works. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 in a Load-Balanced environment (ORM issues) ...
On 2/28/06, ZebZiggle <[EMAIL PROTECTED]> wrote: > I agree that this problem is pretty fundamental. I don't know what > worries me more, the fact that the problem exists or the architects > don't see the problem. I wouldn't put it that. It is a problem and things like transaction support do show up on TODO lists, but right now it is simply not the priority that you would like it to be. Keep in mind that Django encompasses a lot of uses and as has been pointed out, for the majority of uses (the majority of website types), non-"last-write-wins" transaction support is not a priority. Feel free to come up with your own solution and submit a patch if you'd like to get it done sooner, or just wait for the TODO items to move up in the priority list. > I think in my case I can isolate the offending code and use some form > of "double-buffering" technique to solve it. But, it's not going to be > pretty. I would again suggest you take a look at the magic-removal branch <http://code.djangoproject.com/wiki/RemovingTheMagic>. You could encapsulate such code in the actual save() call and fake the Django ORM having that support, and then when Django does provide something that you are happy with you can pull out your custom save() code and the rest of your code probably won't notice. You can even write your own object "Manager" to have fuller control of object caching and to implement said save()-overload code for several model classes. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Model Basics
On 2/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Yeah, we talked about this on Sunday at the Django sprint. The > tentative plan is to introduce a CurrentUserField which is > special-cased in the admin logic. How would this be handled in user code? How would Manipulators deal with these, ie, would Manipulators have to start taking request.user in addition to request.POST? (I'm assuming you've put thought into how this will effect the proposed changes to Automatic Manipulators, as well?) In particular, I have a couple of Models that are created updated during the save() of other Models (ChangeLogs and Changes) and I realize this is a special case, but is there any good way to have have CurrentUser information available to something like the save() without tying it to only the Admin (ie, still allowing custom forms or shell-based modifications)? (On a side note, I could use the ability to have custom non-Model-Fields (ie, not persisted in the database, only used in the save() ChangeLog generation) in the Admin, is there an existing way to do this?) -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: accessing user info in templates
char wrote: > Thanks! I'm still curious though. Why wouldn't user.user work? It is a "magic" issue. Basically the user field prior to magic-removal is simply the metadata container and the get_FOO stuff is auto-generated function to actually get the real data. Magic-Removal changes things up, of course, check out the Descriptor stuff. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Simple weblog, generic views and templates -- error
Sime Ramov wrote: > Hello, > > I'm writing simple weblog and have some problems. I have the > following error when I visit http://127.0.0.1:8000/weblog/ > Page not found (404) > > Request Method: > GET > Request URL: > http://127.0.0.1:8000/weblog/ > No blog.entries available > > I just don't get it, here are the relevant snippets of the files: The obvious question is: have you written any blog entries yet? You won't see anything if you don't have content in the database. After that, keep in mind that the date-based "archive*" views do exactly what they say and only display old/archived entries. So, if you have the date set to some time in the future, there is your answer on why you won't see them. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Please help with django tutorial #2
ak wrote: > Thans for your answer Jason but I think you are wrong. As far as I know > "python manage.py install polls" should create all tables in my DB. It > was done and I can sucessfully load entities from database, modify them > and save them back and I see all these tables and records in mysql. > Even things from tutorial #3 work ok to me and i can create?modify > templates and show things from DB on the site using django. Only admin > stuff doesn't work. And only when I open edit screens, when I see list > items screen everything's just fine. There are three major DB-related steps to do: ``python manage.py init`` ``python manage.py install admin`` ``python manage.py install myapp`` for every myapp The first two you only have to do the first time you initialize the database. Init in particular creates several key tables that are used by the admin and auth, including the Content Types table that is giving you your reported error message. -- --Max Battcher-- http://www.worldmaker.net/ "History bleeds for tomorrow / for us to realize and never more follow blind" --Machinae Supremacy, Deus Ex Machinae, Title Track --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
TZ Interactions
As part of a personal side project I'm taking information from an
external command (a source control system) and marshalling its
information into django model classes.
I hit a small stumbling block and was curious if anyone had any
particular experience.
I'm using Windows for my development environment (yeah, I know), and
without a TZ setting the external app is returning, in one of its
fields, the timezone "Eastern Standard Time", which it is pulling from
Windows. Django is setting the TZ setting to the one in my settings.py
file "America/Louisville". It appears that the application can't make
out how to exactly convert that in a Windows environment and is
returning for the time-zone "Ame", which Python is then in turn not
interpreting as a valid time-zone.
Is there any way in Django itself to convert this, perhaps? Do I need
to just move the uglier ("EST5EDT...") syntax? Is there any "best
practice" in this situation that works well cross-platform?
--
--Max Battcher--
http://www.worldmaker.net/
Re: is_member_of method for user objects
Roberto Aguilar wrote:
In my situation, what I wanted to do was limit the display of a bunch
of menu items depending on the group of the user. I accomplished this
with a for loop and a test for a group:
{% for group in user.get_list %}
{% ifequal group 'desired_group' %}
[...]
It's a two-step process rather than one, but it gets the job done.
That being said, should the menu evaluation go in a view rather than
the template? To me it sounds logical to keep the menu in the
template, but what do the more experienced django developers have to
say?
It depends on the circumstance, as most things do. For simple cases it
might suffice in your template code. However, if you are doing a lot of
logic there and you start to see more {% ... %} than HTML tags, then
that is probably the point when you want to build a {% site_menu %}
custom tag.
That's the key, really. It is it "too much" logic, and that is in some
way an aesthetic judgment.
--
--Max Battcher--
http://www.worldmaker.net/
Re: Recursive self referring foreignkeys
Rudolph wrote:
> With meta.ForeignKey("self") you can create an object that can refer to
> objects from the same type. But how do I prevent loops? (like an object
> that refers to itself, or object A refers to object B which refers back
> to object A). With limit_choices_to I could prevent an object from
> selecting itself, but how do I prevent bigger loops?
The easiest way to iterate through and find a loop during the save()
call of the object. (Using _pre_save() for pre-magic-removal code.)
An example is provided in this cookbook entry:
http://code.djangoproject.com/wiki/CookBookCategoryDataModel
-
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
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 and PCMEF vs MVC
A few thoughts on architecture: http://blog.worldmaker.net/node/211 I had architecture thoughts in my head from class and felt I could apply them somewhat to Django. I'm not sure if its useful or interesting, but hopefully somebody might find use of it or interest in it. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Tree View
Julio Nobrega wrote:
's are possible, it's in fact what I use on my (to-be) site:
{% for node in node_tree %}
{{ node.body }}
{% endfor %}
It's still not semantic (uses presentation style instead of nested
s). It's looking like if I really want a true list view I need to
build a custom tag. Right now I think I'm just going to spread the tree
out across the URL space.
--
--Max Battcher--
http://www.worldmaker.net/
Re: Lookup by week
Adrian Holovaty wrote: On 1/30/06, Jan Rademaker <[EMAIL PROTECTED]> wrote: Would it make sense to implement such a thing? An alternative would be to figure out at what date a week starts and ends and just use pub_date__range, but that's not really the point. I'm just curious how easy/hard it would be to implement. If the above isn't going to work, what's the best/most elegant way to go, __range? Yeah, I'd suggest calculating the week start/end dates in your own code and using the __range lookup. Weeks are a bit of a messy problem -- different people have different definitions of when they start, etc. Then, if weeks are implemented, you start to get requests for fortnights and scores... -- --Max Battcher-- http://www.worldmaker.net/
Re: error restoring project
Luke Skibinski Holt wrote: my hd failed the other day taking my db with it. I'm trying to restore my project now, but I'm getting this error in the admin app: ERROR: missing FROM-clause entry for table "auth_users" SELECT "blogs_blogs"."user_id","blogs_blogs"."title","blogs_blogs"."desc","blogs_blogs"."entriespp","blogs_blogs"."disabled" FROM "blogs_blogs" ORDER BY "auth_users"."username" DESC This is a known issue (http://code.djangoproject.com/ticket/930) dealing with the One-To-One relationship. The SQL is not creating the proper JOIN for the default ordering and you need to explicitly create an ordering='title' in your Meta class so that is isn't ordering based on a field in the other class. I'm assuming this isn't being fixed right now because the Subclassing system will replace it. -- --Max Battcher-- http://www.worldmaker.net/
Re: RoR Ajax helpers port to Django tags?
Eugene Lazutkin wrote: Look at Dojo. I did a small how-to on creating widgets here: http://lazutkin.com/blog/2005/dec/24/live-filtering/. Some people, who read it, missed my point: it was not about Ajax functionality (you can do it with any library), it was about creation of self-contained generic widgets, which don't pollute your html code with unnecessary garbage. You can download LiveFilter.js (link in the tutorial) and use it literally without modifications with practically any form in your project to make it "live". All you have to do is to implement a relatively simple view to support it on Django's side (example included). No JavaScript knowledge is involved in actual use. But if you want to be fancy, you can create your own widgets, and reuse them across projects. Additional bonus (useful for medium-to-large projects): such widgets provide a clean separation between client-side programmers, server-side programmers, and (most importantly) designers --- everybody is doing stuff they are familiar with. Nice example. I think it points towards the basic direction that a Django AJAX framework should take. Client-side code should be in template-vars (ContextProcessor if needed) and template-tags connected to client-side "views" in .js files. Server-side code should consist of simple RESTful views (there are several existing generic views that could easily be used for that task, and there are probably some good ideas out there for other good AJAX-friendly generic views). I think it points to another idea I think would be nice to see in Django: "smart views" (actually, it would really just be a smart template loader and a single additional piece of information needed to pass to the generic views, in order to pass to the template loader). There are several cases where you might have the same view (all of the X objects, details of the X object with id=somenumber, ...), but different output formats based on circumstance. You could let the template loader handle the format... I would use the file extension. For example, you could have your HTML templates as myobject_list.html and your RSS template for the same object as myobject_list.rss. Then you could just add the proper format setting to your info_dict for the generic object_list view and let it choose the proper one. (Assuming for whatever reason you don't want to use the existing RSS Framework, which works well, but this is just the first example to come to mind.) Another example would then be the "simple" views for use in AJAX/REST projects (using .ajax or .rest or .js or .raw.xml depending on the content type, perhaps). You could even design your URLs to take advantage of the format context *if you wanted*. Something like (using an object_detail-style example this time): ``r'^mysite/coolthings/(?P\d+)(?P\.\w+)?/?'`` That would match things like: /mysite/coolthings/1/ (The typical HTML view for a Django site) /mysite/coolthings/1.xml Overall it would be subtle "opt-in" and shouldn't affect the current behavior (ie, if the generic view+template loader doesn't know the expected output format, default gracefully to the default in settings.py). Anyone else see it as useful? -- --Max Battcher-- http://www.worldmaker.net/ "History bleeds for tomorrow / for us to realize and never more follow blind" --Machinae Supremacy, Deus Ex Machinae, Title Track
Re: magic_removal table update
Jason Davies wrote:
ALTER TABLE auth_groups ALTER id SET DEFAULT
nextval('public.auth_group_id_seq'::text);
This was the peculiar incantation I was looking for, thanks. Now I just
have a non-fatal, non-blocking error from the django_content_types table...
--
--Max Battcher--
http://www.worldmaker.net/
magic_removal table update
I'm living on the bleeding edge (just migrated to rev. 2123) with my current development, and followed the suggested ALTER TABLE commands from the wiki page, and though I can read from the data (all of the views work correctly), I can't save because all of the sequences are now out of sync. I tried renaming the sequences to fit the new naming scheme, but to no avail (Django is calling the new sequence name and the table itself still refers to the old sequence name). At this point I'm a bit stumped on how to properly do this. Is there an easy way to resync the sequences in PostgreSQL that I've overlooked? Otherwise, I'm assuming: * Dump the data to a file * Drop Cascade everything * Re-install * Import back from the file I made a brief remark on the wiki page that someone should probably amplify into some better general migration guideline. -- --Max Battcher-- http://www.worldmaker.net/
Re: proper use of admin screens
char wrote: I have a question about the proper use of Django's built-in admin functionality. I realize that Django evolved in a newsroom environment where there is a small number of content publishers/admins and many readers. But what about web apps where users normally enter, update, and delete the bulk of the application's data? Is it considered good practice to use the built-in admin content management functionality as general purpose input screens? The admin site can display a lot of information that you may not want every user to see. One big example is the "Documentation" section (on the top bar). As with any privileged tool, the question is largely one of trust... can you trust all of your potential users with the functionality that you give them in the admin? Another key to keep in mind here is that the current admin site doesn't get more intricate than add/change permissions. If you give someone change permission to one of your models they can change any and all data in that table. Most likely you are going to want to roll your own, as you can be a lot more precise with your own code, but feel free to evaluate your own situation. -- --Max Battcher-- http://www.worldmaker.net/
Re: Admin functionality available on public site
[EMAIL PROTECTED] wrote: Yes, this is what I meant. I'm looking for a way to use admin ui forms in my templates. Here is what I have found, you have two major ingredients for this: Forms and Manipulators: http://www.djangoproject.com/documentation/forms/ Create/Update/Delete Generic Views: http://www.djangoproject.com/documentation/generic_views/#using-create-update-delete-generic-views Mix and match these two in a good cocktail sauce and you have admin-style ui forms ala django. (Mmm, tasty.) -- --Max Battcher-- http://www.worldmaker.net/
Re: Preserving data through db updates/changes
Luke Skibinski Holt wrote:
Absolutely - I had never thought of anything like that before. It's
pretty daunting compared to the easy way (automating the
dumping/reloading and manual editing of sql files). I think the
implementation of such a beast would be very difficult though - there
are too many gotchas that have broad impact on the rest of the db. It's
easy enough to prune away at a model but the real difficulties come
when you want to add new fields, especially required fields.
I was just hoping for some django magic to do it all for me ;)
I've done some thinking about this with past (php) frameworks, and it
does strike me as odd that after all the work we put into automating
version control of our source code and our desktop installers... but
yet we don't have much of use for data schemas beyond hand writing SQL,
which can often be imprecise (maybe you forgot a few changes) and in the
case of using a decent ORM is not very DRY.
Obviously the full implicit system is out of bounds for some of the
reasons the parent mentions. We worry about our data if a fully
implicit system is doing the work. On the other hand, the fully
explicit techniques mentioned further up the message family aren't DRY
and can get annoying/irritating.
The key to any endeavor into such a field would be to step gradually in
the direction of a true modern version control. Here's some of the
steps that I see:
* How about an ``sqldiff`` command to sit beside the others like
``sqlclear`` and ``sqlreset``? You have the model, you have the current
db schema... show me what the differences are and I'll have a quicker
time in writing SQL to fix that. Even cooler: I'm using version
control, if I give the tool two model files, could you give me the
difference between the two in terms of the SQL? Neither of those should
be that tough, should they? But both should be that much more useful in
moving to a good model versioning system.
* How about a useful Schema Introspection API? Things like
``MyModel.objects.db.has_field('my_field_name')``... Not only would
this be useful for migration scripts (``if not
MyModel.objects.db.has_field('my_field_name'): # Add Field SQL
Script``), and fun things like automatic migration on the first save(),
but could be useful for creating "polymorphic" models that adapt to the
current db schema (for instance, I was thinking about very modular
systems that have "installable" options, and the current easiest way to
do this would be to have seperate "glue apps" with relational models,
but it would be neat to have models react to whether or not other
models, or certain fields of their own model, are "installed" in the
database).
* Then, how about a useful "Schema API" to add the fields and update the
fields based on the Model information? Once you have
``MyModel.objects.db.has_field('my_field_name')``, then you can think
about things like ``add_field()`` or ``update_field()``. With those
even cooler migration scripts could be built, and it could make it real
quick to update a database from the Python console.
Those are my thoughts at the moment, feel free to see if they are useful
or necessary. ("Do the simplest thing, but no simpler", right?)
--
--Max Battcher--
http://www.worldmaker.net/
Re: create object method
The Boss wrote: that was needed. one problem with django i guess is figuring out what exactly are the correct names and hierarchy, Precisely, which is why the magic-removal branch has changed this particular annoyance (model classes now don't jump to a different namespace) and a few others. I had enough problems dealing with the magic that I went ahead and moved my development to magic-removal... See http://code.djangoproject.com/wiki/RemovingTheMagic -- --Max Battcher-- http://www.worldmaker.net/ "History bleeds for tomorrow / for us to realize and never more follow blind" --Machinae Supremacy, Deus Ex Machinae, Title Track
