Feel proud today, very very proud especially of 0.95 and MR
Hi Django developers, So for those of you that I haven't met or corresponded with, I'm the founder of Tabblo, a relatively young website for telling stories with photos, words, and highly stylized templates via a 100% web-based interface that is usable by normal humans. We've been using Django since day 1 of Tabblo and have been really happy about how much help its been. Frankly, despite having been the guy who picked it, I had originally thought that building a massively scalable site on Django was going to be a non-starter after we got past the initial phase and was just happy to start it for prototyping due to the niceties the URL mapper and the ORM provided. Boy, have you guys proven me wrong! Anyhow, this week, we completed our migration to 0.95 and magic removal which was painful but has shown us how much more great work you guys have been up to. Before the move, we were running on a hacked version of 0.91 that we had spent some cycles optimizing, mostly around ORM caching, and my big fear was that when we rolled live with MR, we were going to see all sorts of crazy slow-downs. Again, I am thrilled to have been proven wrong. I wanted to do something nice for those of you that like the kind of thing that we do at Tabblo (see here: http://app.tabblo.com/studio/view/favorites/antonio for some examples) and after talking to Adrian, we've decided that the simplest most direct thing would be to offer anyone who is so inclined a coupon for a free poster. Since we don't normally do this kind of thing, the process for getting it is going to be a little cumbersome: just send me an email (antonio at tabblo dot com) with the subject line "I am a Django developer" and I'll make sure you get the coupon within a couple of days. In the meanwhile, feel free to play with the site and take pride in what you've helped us accomplish. Standing here on the shoulders of giants, Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: urlify.js blocks out non-English chars - 2nd try?
On 7 Jul 2006, at 11:06, Bill de hÓra wrote:
> What's the expected scope of the downcoding? Would it be throwing a
> few
> dicts together in the admin js, or a callback to
> unicodedata.normalize?
I’m not sure unicodedata.normalize is enough. It kind of works, if
you do something like:
def slugify_utf8_slug(slug):
normalized = []
for c in slug.decode('utf-8'):
normalized.append(unicodedata.normalize('NFD', c)[0])
return ''.join(normalized)
Then it works for simple slugs:
>>> slugify_utf8_slug("müller")
u'muller'
>>> slugify_utf8_slug('perché')
u'perche'
But this is because “ü” and “é” can be decomposed as “u”
and “e” plus accent or diacritic. But then you couldn’t have
language-specific decompositions like the “Ä = Ae” mentioned here:
http://dev.textpattern.com/browser/releases/4.0.3/source/
textpattern/lib/i18n-ascii.txt
Also:
>>> print slugify_utf8_slug("Δ")
Δ
So this would be no good.
Perhaps I’m missing something but unicodedata won’t cut it. If
we’re going the asciify-route, we need a lookup table.
Cheers.
--
Antonio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: urlify.js blocks out non-English chars - 2nd try?
On 17 Jul 2006, at 8:25, tsuyuki makoto wrote:
> We Japanese know that we can't transarate Japanese to ASCII.
> So I want to do it as follows at least.
> A letter does not disappear and is restored.
> #FileField and ImageField have same letters disappear problem.
>
> def slug_ja(word) :
> try :
> unicode(word, 'ASCII')
> import re
> slug = re.sub('[^\w\s-]', '', word).strip().lower()
> slug = re.sub('[-\s]+', '-', slug)
> return slug
> except UnicodeDecodeError :
> from encodings import idna
> painful_slug = word.strip().lower().decode('utf-8').encode
> ('IDNA')
> return painful_slug
I’m not convinced by this approach, but I would suggest using the
“punycode” instead of the “idna” encoder anyway. The results don’t
include the initial “xn--” marks which are only useful in a domain
name, not in a URI path. Also, the “from encodings […]” line appears
to be unnecessary on my Python 2.3.5 and 2.4.1 on OSX.
[[[
>>> p = u"perché"
>>> from encodings import idna
>>> p.encode('idna')
'xn--perch-fsa'
>>> p.encode('punycode')
'perch-fsa'
>>> puny = 'perch-fsa'
>>> puny.decode('punycode')
u'perch\xe9'
>>> print puny.decode('punycode')
perché
>>> pu = puny.decode('punycode') # it's reversible
>>> print pu
perché
]]]
More on Punycode: http://en.wikipedia.org/wiki/Punycode
Cheers.
--
Antonio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: XHTML vs. HTML4 and csrf middleware in particular
Hi Michael, On 17 Oct 2006, at 12:00, Michael Radziej wrote: > Large part of Django seems to use xhtml, and I like it somehow > better than html, so I use it and give to browsers that accept it > application/xhtml+xml as media type (and to others I feed the same > input but call it text/html). this is slightly orthogonal to your question, but bear in mind that when served as application/xhtml+xml the page is parsed differently from the browser. For example, Javascript requires namespace-aware methods for DOM manipulation on application/xhtml+xml documents, so your scripts will likely break from one version to the other. This is not the only problem, many others have been outlined in these two articles that I strongly advice you to read: http://hixie.ch/advocacy/xhtml http://webkit.org/blog/?p=68 Since you stated you’re serving the same content with different MIME types, you may be on a slippery slope there. HTH, -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: XHTML vs. HTML4 and csrf middleware in particular
On 17 Oct 2006, at 12:21, Michael Radziej wrote: > Antonio, you're probably suffering from a severe read-only-first- > paragraph syndrome here. Proposed cure is to read email again until > bottom hits ;-) Michael: you’re right, I’m a moron :-) Sorry for wasting everyone’s time. Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: drag-n-drop order_with_respect_to
Hi Russell, On 18 Oct 2006, at 14:49, Russell Cloran wrote: > I'm currently writing an application which would benefit greatly > from an already-existing drag-n-drop interface for something like > the order_with_respect_to option. > > Is there somebody working on this? Last I heard on this issue is this ticket: http://code.djangoproject.com/ticket/13 But that hasn’t gotten much of love, last “action” is from around January. The mockups from Wilson look nice anyway, maybe they’re helpful for your needs. > Would a resurrection of a drag-n-drop UI for order_with_respect_to > be welcomed? Yeah. I, for one, would very much welcome something like it. BTW: is this code working at the moment? http://code.djangoproject.com/browser/django/trunk/django/contrib/ admin/media/js/admin/ordering.js Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Re: How do i run just 1 test module?
On 11/14/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > Curious, does the new testing setup contain any mechanism for running > tests for my own applications, say in a package /tests instead > of in modeltests/ or regressiontests/ ? Yes. There is preliminar documentation for the new testing framework here: http://www.djangoproject.com/documentation/testing/ That document is not yet linked from the main documentation page for a reason: the testing framework is being worked on and the APIs may change, but in case you're impatient that should get you going. BTW, for Russ: the testing framework is amazing, it changed completely how I go about designing models for my own apps. Thanks for that! I'm looking forward to the fixtures support. Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature request for newforms: HTML 4
On 12/5/06, James Bennett <[EMAIL PROTECTED]> wrote:
> Now, I'm pretty picky about my markup, and I'm certainly willing to go
> to unusual lengths to get it just the way I want it, but it'd be
> awfully nice if there were some way to get HTML-style output from
> newforms without having to manually subclass all the widgets and
> override their rendering to remove trailing slashes.
+1 to this proposal. I found myself writing the code below, which is
quite scary but does the trick:
[[[
from django import template
"""
Remove XHTML endings from tags to make them HTML 4.01 compliant
Usage:
{% load html4 %}
{% html4 %}
My long template with {{ variables }} and
{% block whatever %} blocks {% endblock %}
{% endhtml4 %}
"""
def do_html4(parser, token):
nodelist = parser.parse(('endhtml4',))
parser.delete_first_token()
return Html4Node(nodelist)
class Html4Node(template.Node):
def __init__(self, nodelist):
self.nodelist = nodelist
def render(self, context):
output = self.nodelist.render(context)
return output.replace(' />', '>')
register = template.Library()
register.tag('html4', do_html4)
]]]
Cheers.
--
Antonio
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---
Re: Re: Re: Feature request for newforms: HTML 4
On 12/5/06, James Bennett <[EMAIL PROTECTED]> wrote: > On IRC a moment ago, Jacob suggested an 'html4' template filter which > would just strip trailing slashes from empty tags; I'd be happy with > that (and willing to put in some time to implement it), provided we > advertise clearly that the Django forms system is going to produce > XHTML and that if you want HTML4 you'll need to use the filter. I posted a tag earlier in this thread that does what you ask (it's pretty trivial). Are my messages coming through, anyway? -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Re: django.contrib.formtools: High-level abstractions of common form tasks
On 12/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > This would be a great addition. Rather than requiring sessions, what > do you think of passing intermediate form data in hidden fields? Isn't that the way the dreaded ASP.NET "view state" works? Saving marshaled temporary data in a hidden field? Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Re: django.contrib.formtools: High-level abstractions of common form tasks
On 12/7/06, Waylan Limberg <[EMAIL PROTECTED]> wrote: > Presumably each page would do validation on submit (we don't want to > send the user back to page one after completing 10 pages). If the > validated data is now in hidden fields, couldn't someone alter that > data (with evil intent) requiring re-validation? Wouldn't storing the > data in sessions avoid that? You could probably have a partial validation, per-page, and a complete one on the final page, essentially re-validating all the fields. HTML-escaping of these hidden fields values would be mandatory in all cases anyway. Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
On 8 Dec 2006, at 19:10, JP wrote: > What I've always done in these cases is carry a MAC along with the > hidden data and just validate that the hidden data hasn't changed by > re-hashing it after each form submit. You don't really need to > re-validate the already-validated data, you just need to ensure > that it > hasn't changed since you validated it. MAC? An MD5/SHA1 hash, probably? -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: JS Form Validation (was Re: Django and AJAX: Setting aside the conflict)
Hello everyone, first post on the list, I’ll be introducing myself at the bottom of this message. On 17 Nov 2005, at 11:51, Christopher Lenz wrote: While there are definitely many types of validations that can't be performed on the client side, calling back to the server just to check whether e.g. a text-input is empty is overkill IMO. The same goes for validity checks for common things like text fields expecting an email address or date. I'd prefer a hybrid approach, where simple javascript validation checks are generated, and the others are performed via AJAX callbacks. I don’t agree with this approach. While I think client-side validation is fine and dandy, and from a user perspective is definitely the way to go, we cannot rely on it. It’s not like we’re in 1999 when we could develop a “DHTML”- cool-whiz-bang inaccessible piece of crap and still expect to get along with it. We’re in 2005, and we *know* that some people turn JS off on purpose, use browsers where JS support sucks, or are disabled and we cannot feed them some of the “dynamic” stuff we think is so cool, because they just won’t be able to use it. We also don’t want to have to mantain the same code in two places: email-validation in JS on the client and email-validation on the server (yes, I’m oversimplifying, but you get the idea). So I think the best way for Django, “the web framework for perfectionists with deadlines” is to do The Right Thing™ and have some sort of support for dynamic, JS-based form validation on the client powered by the same logic that powers the server-side, and this is where JS libraries and “AJAX” interactions fit in, IMHO. Bottom line: JS/AJAX stuff, yes but only if it’s done right, which means accessible and done in a context of progressive enhancement. What do you guys think? -- Antonio About me: I’ve been hacking with Django for some weeks now, I’ve been developing websites for almost 8 years now and I used to code in PHP/JS/ActionScript/XSLT. I’ve been moving to Python for the last year and a half and Django was a godsend in that regard. My first and only contribution to the project so far has been this rather outdated guide to get Django on OS X: http://cavedoni.com/2005/django-osx I had also planned to contribute the code to produce Atom feeds from the syndication framework, but somebody beat me to it by a couple of days (damn!).
Re: A fix for all that futzing around with paths
On 18 Nov 2005, at 19:37, Simon Willison wrote: On 18 Nov 2005, at 18:26, David Ascher wrote: It's very possible that the use case it supports (repeatedly switching b/w projects when invoking django-admin.py) isn't frequent enough to warrant the increased complexity. It's frequent enough to drive me potty. I think I'll try to knock up a patch for it at the weekend. Environment variables are a complete pain, and anything we can do to reduce the need for them is a bonus as far as I'm concerned. I may not speak for every django user, but I have aliases set in my .bash_profile to switch from one django project to the other, just so that I don’t have to see or type DJANGO_SETTINGS_MODULE too much. So, any solution that rids me of environment variables is definitely welcome. Cheers. -- Antonio
Re: Ditch pluralisation entirely
On 23 Nov 2005, at 13:03, Simon Willison wrote: Here's an easy lesson we can learn from Rails: pluralisation sucks. Person -> People, Family -> Families etc is all very pretty but at the end of the day you're constantly left asking yourself if the bug you are facing would be fixed by adding or removing an S. +1, let’s get rid of pluralisation altogether. It’s also bad for newcomers: in my first django app I used to have “newss” :-/ Cheers. -- Antonio
Re: Proposal: Django should support unicode strings
On 10 Jan 2006, at 21:24, hugo wrote: The patch to #914 is just sitting there because there is no comment from the core devs on it - but I think we should do either the unicodefication or the patch from #914, with my preference being the unicodefication. I’m +1 on the full unicodefication and I’m willing to help implement it. Maybe we could start a “unicode” branch right after “magic-removal” is merged back into the trunk? -- Antonio
[OT] Re: Proposal: Django should support unicode strings
On 12 Jan 2006, at 14:44, Simon Willison wrote: http://www.flickr.com/services/api/misc.encoding.html ROTFL! Could you make that text a bit bigger? I’m not sure which encoding is expected by the Flickr API :-p -- Antonio
Re: dot can't match in url configuration
Hey Chris, On 21 Jan 2006, at 15:30, [EMAIL PROTECTED] wrote: The default django url configuration system seems does not allow url with "dot", i.e. I need url like "http://mysite.com/user/ favorate/web2.0", but this url con't match any url configuration even I use following config: (r'^user/favorate/(?P.*)$', 'test.fav.index'), how about something like this? (r'^user/favorate/(?P[a-zA-Z0-9\.]*)$', 'test.fav.index'), Also: shouldn’t favorate be spelled “favorite”? -- Antonio
Re: magic-removal: "Change subclassing syntax"
On 26 Jan 2006, at 0:02, Jeremy Dunck wrote: This makes me think the world needs a wiki whose wikitext syntax is restructured text. Anybody know of one? Apparently you can use ReST with MoinMoin: http://moinmoin.wikiwikiweb.de/HelpOnParsers/ReStructuredText It’s not the native wikitext, but support can be added in. Cheers. -- Antonio
Restarting the webserver under mod_python
Hello everyone, Shannon (whom I’m CC-ing this message to), In his recent “Django-palooza” blog post Shannon was mentioning having a fix for not having to restart the webserver at each code change under mod_python. http://jjinux.blogspot.com/2006/02/python-django-palooza.html I’d be interested to know how this works and whether it’s possible to make it play nice with Django’s mod_python handler. Shannon, if you don’t mind I’d ask you to join the django-developer mailing list and reply to that address so everyone can join the conversation, thanks. http://groups.google.com/group/django-developers Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Django on Google App Engine via SQL (not nonrel)
Hi Wesley, Maybe it would also be helpful to point out in advance what known behaviors (often considered as limitations) of the datastore will be carried to the MySQL compatibility layer that Django would have to deal with. For example, currently using GQL counting the number of rows returned by a query is/was really tricky because of the 1000 rows limit. I also recall there was a 1 MB limit on the size of every item you could store. I've collected some links regarding this kind of stuff that I'm including here: http://aralbalkan.com/1504 http://stackoverflow.com/questions/421751/whats-the-best-way-to-count-results-in-gql http://stackoverflow.com/questions/264154/google-appengine-how-to-fetch-more-than-1000 http://stackoverflow.com/questions/703892/whats-your-experience-developing-on-google-app-engine http://blog.burnayev.com/2008/04/gql-limitations.html Hope this help a bit discuss this matters, Antonio Lima-Peru -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Authentication using email
Hello everyone, For my current project I'm replacing the username with the e-mail address wherever the end-user sees it. I haven't had to implement a different authentication backend since I'm saving the email address with the @'s and dots replaced with underscores as the username field for the django.contrib.auth.models.User model. So far, I've customized my registration form getting rid of the username field and simple deriving it from the e-mail field inside the save() method of the registration form. In the login form I ask the user to type an e-mail address and then I wrap the view at django.contrib.auth.views.login with another view that copies the POST QueryDict of the request in order to make it mutable and have the username prepared as needed. It's a bit of an ugly hack but for now it works. My problems have started when I realized I could log in as both [EMAIL PROTECTED] and john_company_com with the current approach so I wanted to replace the login form with a custom form in which the username field has been turned into an email field implemented using a proper forms.EmailField field. The issue is django.contrib.auth.views.login doesn't accept a custom form as parameter only a custom template so I'm kind of forced to copy and paste 27 lines of Django internal code into a custom view to essentially use my own custom form because currently the form is hardcoded to be django.contrib.auth.forms.AuthenticationForm. I searched through the tickets and found #8274 that patches Django to do exactly what I need it to do and it looks it might make it into 1.0 since it's marked "1.0 maybe". I could move completely to using an alternative authentication backend but the main reason I haven't already do it because of the admin preventing me from logging-in with my email address even if the authentication backend would accept it. The ticket for this bug is #8342. I run Django from trunk updating almost everyday in order to be fully ready for 1.0 :) So, what chances do you think this two tickets have to make it into the 1.0 release? Is there anything else that can be done to make it happen? Yes, I know there are patches for both issues but I really want to avoid depending on a patched Django. Regards and thanks for your time, Antonio. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Search facility for new documentation
On Sun, Aug 31, 2008 at 1:53 PM, Fraser Nevett <[EMAIL PROTECTED]> wrote: > Sphinx's search could be useful if you're working with an offline copy > of the docs, but Google seem to give much better results so is > probably preferable for the docs web site. FWIW: I have an almost finished (only needs packaging and some documentation) reusable Django app that wraps around Google Business Search. It's basically the same thing as the Google Custom Search that's currently in place, only it doesn't work off an iframe and doesn't have any ads. The downside is that it's for pay, about $100 a year IIRC. My app would be free anyway. If there's interest I can package and release it. Cheers. -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Search facility for new documentation
Hi Jacob, On Tue, Sep 2, 2008 at 5:06 PM, Jacob Kaplan-Moss wrote: > Yeah, I'd love to see it; if it integrates better -- the custom search > looks like shit, frankly -- it might be worth the money. See here: http://code.unicoders.org/wiki/DjangoGoogleSearch There's some documentation now, although this is of course not a proper public release. I've been using this code in production for a while now and it hasn't crashed on me yet, but of course your mileage may vary. I've been using it in production here for about five months now, without any major issues: http://mytech.it/search/?q=test HTH, -- Antonio --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
help with ZINNIA
Hallo,
sorry could someone help me fi installation of zinnia.
My pip freeze:
BeautifulSoup==3.2.1
Django==1.4.5
PIL==1.1.7
Pillow==2.5.2
South==1.0
argparse==1.2.1
beautifulsoup4==4.3.2
django-blog-zinnia==0.11.1
django-contrib-comments==1.5
django-mptt==0.5.5
django-tagging==0.3.2
django-xmlrpc==0.1.5
docutils==0.12
pyparsing==2.0.2
pytz==2014.4
wsgiref==0.1.2
My settings file:
"""
Django settings for blogZ project.
For more information on this file, see
https://docs.djangoproject.com/en/1.6/topics/settings/
For the full list of settings and their values, see
https://docs.djangoproject.com/en/1.6/ref/settings/
"""
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))
SITE_ID = 1
# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/1.6/howto/deployment/checklist/
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'k26mbfv&*onj^v@zi!q96i9a5=*ae=@&(&vy7*@3x=nmb_+ws+'
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
TEMPLATE_DEBUG = True
ALLOWED_HOSTS = []
# Application definition
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'django.contrib.sites',
#'django.contrib.markup'
#'django_comments',
'south',
'mptt',
'tagging',
'zinnia',
)
MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
if DEBUG:
TEMPLATE_LOADERS = [
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
]
else:
TEMPLATE_LOADERS = [
('django.template.loaders.cached.Loader',(
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
'forum.modules.template_loader.module_templates_loader',
'forum.skins.load_template_source',
)),
]
TEMPLATE_CONTEXT_PROCESSORS = (
'django.contrib.auth.context_processors.auth',
'django.core.context_processors.i18n',
'django.core.context_processors.request',
#'zinnia.context_processors.version', # Optional
)
ROOT_URLCONF = 'zinnia.urls'
WSGI_APPLICATION = 'blogZ.wsgi.application'
# Database
# https://docs.djangoproject.com/en/1.6/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}
# Internationalization
# https://docs.djangoproject.com/en/1.6/topics/i18n/
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_L10N = True
USE_TZ = True
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.6/howto/static-files/
STATIC_URL = '/static/'
I use:
mkvirtualenv --no-site-packages
--
I have followed all the steps (syncdb, migrate and so on)
===
on the web the errors is:
TemplateSyntaxError at /
'comments' is not a valid tag library: Template library comments not found,
tried
django.templatetags.comments,django.contrib.admin.templatetags.comments,django.contrib.staticfiles.templatetags.comments,mptt.templatetags.comments,tagging.templatetags.comments,zinnia.templatetags.comments
Request Method:GETRequest URL:http://localhost:8000/Django
Version:1.4.5Exception
Type:TemplateSyntaxErrorException Value:
'comments' is not a valid tag library: Template library comments not found,
tried
django.templatetags.comments,django.contrib.admin.templatetags.comments,django.contrib.staticfiles.templatetags.comments,mptt.templatetags.comments,tagging.templatetags.comments,zinnia.templatetags.comments
Exception
Location:/home/antonio/.virtualenvs/npopblog/local/lib/python2.7/site-packages/django/template/defaulttag
Re: Django 1.0 features -- the definitive list
On Nov 30, 1:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > I think we ought to call the release 2.0. Adrian, marketing matters. :) How about releasing 1.0 now, 1.2 in a month or so, and then 2.0 when all the features listed above will be implemented? Cheers, Antonio -- Antonio Cangiano http://antoniocangiano.com http://math-blog.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Hello Django developers
Hi, My name is Juan Antonio (aka ersame) from Spain and I am a computer science student . I have been enrolled in some Django projects since September 2010. I think it’s time to start contributing in this amazing project. I just want to say hello to everybody and if someone could make a review of my first ticket (http://code.djangoproject.com/ticket/15175) I would be very grateful, because I do not know if I am doing it well. By the way, congratulations to the Spanish (Castilian) translation team we almost finish. Thank you all and regards, Juan A. Infantes. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Hello Django developers
Thank you ! :) 2011/2/7 Lachlan Musicman > On Mon, Feb 7, 2011 at 11:40, Russell Keith-Magee > wrote: > > On Mon, Feb 7, 2011 at 6:24 AM, Juan Antonio Infantes > wrote: > >> Hi, > >> > >> My name is Juan Antonio (aka ersame) from Spain and I am a computer > science > >> student . I have been enrolled in some Django projects since September > 2010. > >> > > Your patch addresses the problem in a reasonable way, there's a test > > to validate the edge case in question. There's no docs required > > because it's just a bug. That's all we need, so I've just marked the > > ticket Ready For Checkin. > > Juan, Congrats! > L. > > -- > Crunchiness is the gustatory sensation of muffled grinding of a > foodstuff. Crunchiness differs from crispiness in that a crispy item > is quickly atomized, while a crunchy one offers sustained, granular > resistance to jaw action. While crispiness is difficult to maintain, > crunchiness is difficult to overcome. > from The Best of Wikipedia http://bestofwikipedia.tumblr.com/ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Juan Antonio Infantes Díaz -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
reassessing our Operating System
Hi Everyone. I'm looking at reassessing our Operating System of choice for our Django site, and I really need some background information (popularity & suitability mainly) If you have a minute spare I'd really appreciate some answers to the following questions: (live publicly viewable sites only) 1. What OS are you using to run Django on? 2. What OS do you think is most popular for running Django on? 3. What OS do you think is most suited for running Django on? (non publicly viewable sites) 4. What OS do you think is most suited for developing Django on? Any free form comments on choosing an OS for Django would be much appreciated! ~Love your work in advance. Carmoda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
py2exe + Django 1.6
Hi everyone, I was using py2exe + Django 1.3 without problems. From Django 1.4 the way to find the commands changed and it tries to find .py files as you can see in the find_commands() function in the file core/management/__init__.py . When you compile Django using py2exe, your don't have .py files, just .pyc and manage.exe won't have any command. I have tried to modify the find_command() function but the result was negative. Also, I have tried to run commands manually but the functions try to find .py files as well. Did anyone manage to do it? Cheers -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/98506afa-0514-414a-8285-f5692ac742a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Sending messages to the group does not work after a few minutes online
I'm using:
Django==1.11.3
channels==1.1.6
When the user connects to the websocket, I do the following:
@channel_session
def connect(self, message, **kwargs):
group = Group('user-%s' % user.uuid)
# Do not use more than one device.
group.send({"close": True}, immediately=True)
group.add(self.message.reply_channel)
I've created this method to send information to some specific user:
from channels.generic.websockets import WebsocketMultiplexer
def custom_reply(uuid: UUID, stream, action, data={}, response_status=200):
if type(action) is ActionType:
action = action.value
payload = {
'errors': [],
'data': data,
'action': action,
'response_status': response_status
}
WebsocketMultiplexer.group_send(name='user-%s' % uuid,
stream=stream,
payload=payload)
For several minutes this method sends the message to the client, after a
while it seems that the users within the group are being reset and then the
client is losing message
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/4a819a9c-b791-4c89-a996-09ab2e07a2ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
