Using a block more than once.
I have some templates I'm using to produce static content, and in the base template, there's a block called 'title' used for the page title. I also want to use the same text content for the page title displayed in the body, and in a few other places, however this doesn't appear to be possible. Does anyone have a solution to this problem that doesn't involve putting the title into the context passed to the template render? TIA, John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Generating Javascript w Django
On Friday 12 January 2007 16:04, cwurld wrote: > Hi, > > Does this make sense? I wanted some code to cycle thru some banner ads. > I could have done it with dojo doing a callback to my view, have my > view send the image path and the corresponding url, but that seemed > like a lot of activity for such a simple process. > > Instead, I generated the javascript as a string, including the list of > images and urls as variables in the script, then I passed the string > containing the javascript code as a variable that got inserted in the > template. It works. But it seems like a strange way to solve this > problem. You could use the JSON support in a view which just returns a chuck of JSON, which is just a javascript data structure, containing all your images and urls, then include that as an external script loaded by the page. John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: mysql MyISAM save woe
On Tuesday 12 December 2006 17:26, Adrian Holovaty wrote: > On 12/11/06, John Morton <[EMAIL PROTECTED]> wrote: > > The database introspection was correctly detecting which field to set as > > the primary key, but failed to detect that that column was > > autoincrementing—it should have assigned AutoFields instead of > > IntegerFields. > > > > Bug? Should I file it? > > Yes, definitely go ahead and file that. Looks like the "inspectdb" > option should do a better job of detecting AutoFields on MyISAM > tables. (Have you confirmed it only happens on MyISAM tables, as > opposed to the other MySQL table types?) Not at this stage, but I could probably put together some test cases before filing the bug. John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 -~--~~~~--~~--~--~---
mysql MyISAM save woe
I'm working with an introspected model against tables in a mysql backed with the MyISAM engine, and I'm having problems when creating new objects. Basically, I instantiate a new instance of the model, save the new object with the save method, then test the primary key attribute. Except that the primary key attribute is always None, instead of the insert id from the autoincrementing primary key column. All is good in the database, so I'm guessing that whatever the backend code is doing to grab the insert id of the last transaction isn't working for MyISAM tables, as they don't do transactions. Anyone else experienced this? John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 -~--~~~~--~~--~--~---
TextField and mysql text columns
I've got a model built out of a database introspection on a mysql MyISAM table which has a 'text' column which maps to a TextField. The problem is that this field ends up being an array object of characters, rather than just a string, as I expected. Is this behaviour consistant for all TextField field types, or is it peculiar to mysql? John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Python 2.5 anyone
On Thursday 21 September 2006 05:44, John DeRosa wrote: > Oliver Andrich wrote: > > Hi, > > > > I am running Django 0.95 . And so far I can't see any problems. > > How'd you do it? > > I'm on Windows XP. I installed Python 2.5 from python.org without a > problem. > > But then I found that pysqlite Windows binaries for Python 2.5 don't > exist, and neither does setuptools. Trying to install Django 0.95 on > top of Python 2.5 gives me this: pysqlite2 comes bundled with python 2.5. John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Python 2.5 anyone
On Wed, 20 Sep 2006 07:53, James Bennett wrote: > On 9/19/06, Ramdas S <[EMAIL PROTECTED]> wrote: > > Is anyone running Django dev version on Python 2.5? Will it work or are > > there any issues? > > Python 2.5 doesn't break or remove anything, it just adds some new > features. So it should work just fine. Backwards compatibility of > Python releases should be maintained up until Python 3.0, at which > point everything gets thrown out the window :) That's not strictly true. There is a list of porting considerations here: http://docs.python.org/dev/whatsnew/section-other.html Nothing major this time around, but the C API changes may be an issue for some of the database driver dependencies. There are a few deprecated modules that have been removed as well, but that's unlikely to affect Django. John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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: Weird slowdown with dev server behind nat
On Monday 31 July 2006 22:04, Akatemik wrote: > I'm running the basic django server and everything works fine from lan. > But from outside every request has a three second overhead, even if > it's just a 304. This means that a small html-page with three JS-files > and a stylesheet takes 15 seconds to load. > > With apache everything works fine even from wan. I also did tcpdumps at > my external and internal interfaces on my firewall, which show that the > packets aren't delayed by the fw by no more than 0.1ms. They also show > that the ack for the GET is returned almost instantly but the http > payload doesn't begin to send until about three seconds later (at least > according to my limited knowledge of ethereal). Once the sending > starts, it's all finished in milliseconds and the next lag occurs when > the client GETs another file. > > Any idea what could be happening? It's making development testing quite > hard, since all my volunteer testers get fed up with waiting for > pageloads. In my experience, when you encounter non-obvious but fairly consistant slow downs in net traffic, the first thing to check is DNS. In this case, I'd make sure that each of the DNS cache servers that the client consults to resolve the address of your server can perform both a forward and reverse lookup of your server's name an IP. Conversely, make sure the server isn't being slowed down by failed attempts at reverse lookups on the client. HTH, John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
