Re: 1.2 Proposal: django debug toolbar in contrib
I'm not sure if this is the place but here are some other issues or questions I have if this were to happen... * The jQuery question is a big one. I've taken strides to make the debug toolbar interoperate with other popular JS frameworks (mootools and prototype, namely). But if jQuery were decided against, would it make sense to re-use some of the Javascript libraries that Django has developed for its admin? Would it use the same admin media handler trick? * Which set of plugins are included, and of those that have settings, what are their defaults. Some defaults currently optimize to general case and provide more debugging information, but on larger sites performance may suffer severely. It may make sense to take a philosophy of best default performance with opt-in added debugging. * Should there be a place for plugins (panels) that don't make the cut? Panels consist of some Python and some HTML, so it's not a single file. They *could* be changed to work similar to form.widgets with a render method and HTML backed in... but I'm not a huge fan of that. But it would make it a bit easier for posting on a site like Django Snippets. * Should the UI match that of the Django admin (overall theme, colors, etc)? * If the debug toolbar is incorporated, should we consider different integration options? e.g. Currently the debug toolbar injects URLs into the project in a rather ugly way -- could this be done better if it were part of Django? Thanks, Rob --~--~-~--~~~---~--~~ 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: Suggestion: Better way to extend user table
Take a look at ticket 3011: http://code.djangoproject.com/ticket/3011 --~--~-~--~~~---~--~~ 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: 1.2 Proposal: Add a few more tutorial steps
On Thu, Aug 20, 2009 at 1:03 PM, Nicolas Steinmetz wrote: > Maybe you can inspire from the Jobeet [1] tutorial which consists at the > beginning as an advent calendar (a one hour tutorial published > everyday). Jobeet is a Job board and allow to deal with all aspects of > Symfony framework from framework installation to deployment. > > Building a job board as a *real* app is I think more interesting than a > basic poll app that nobody will use or do not look like a real app. I very much agree with this and would be on board to help. Using a full website as a tutorial allows for explanation of topics you might not get in a simple example tutorial — things like deployment, caching, tests, data/schema migration as models evolve (though not currently part of Django), feeds, internationalization, etc. I don't know that I'd necessarily copy what Jobeet has done, but perhaps something that's already being used in the Django community, is open source, and could be improved a bit. Something like DjangoSnippets perhaps? -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: Better HTML4 support
Or: Why is HTML4 such a PITA to get right?
Outline:
* What I know about HTML4 and Django
* Some info about past efforts and discussions
* Thoughts and curiosities about what we can do
What I know about HTML4 and Django
First, let's not let this turn into an argument about HTML vs XHTML.
People have their preference one way or the other, and I believe
Django should be agnostic.
Currently, however, Django *is* biased to producing XHTML output in
the various places that output HTML, such as comments, formtools,
csrf, forms.widgets, and various filters and HTML utilities that
output "" tags. For someone that prefers an HTML4 doctype, this
is a hassle with no easy answer.
Some info about past efforts and discussions
=
Some tickets already open on this...
Ticket #6925: CSRF html output is not valid html (it is xhtml)
http://code.djangoproject.com/ticket/6925
Ticket #7281: Add doctype tag to webdesign template tags
http://code.djangoproject.com/ticket/7281
Ticket #7452: Settings for HTML4 or XHTML output
http://code.djangoproject.com/ticket/7452
Proposal from Mar 2008:
Form rendering with filters...
http://groups.google.com/group/django-developers/browse_thread/thread/5f3694b8a19fb9a1
Proposal from Sept 2008:
{% doctype %} and {% field %} tag for outputting form widgets as HTML
or XHTML...
http://groups.google.com/group/django-developers/browse_thread/thread/f04aed2bc60274f0
Since those tickets aren't closed as "wontfix" or "invalid", and much
of the conversation surrounding this agrees that *something* should be
done, I'm hoping to start a conversation as to what that something
might be.
Thoughts and curiosities about what we can do
==
After thinking for some time, I've only been able to come up with two ideas...
1. Incorporate something along the lines of Simon's django-html
project (http://github.com/simonw/django-html).
I think the genera idea is this: You set a doctype in your base
template via a template tag (e.g. {% doctype "html4" %}, and any
rendering that is done after that (in inherited or included templates)
is based on this doctype.
Advantages:
* It puts the doctype decision into the hands of the designer.
* It allows for different parts of an application to have different doctypes.
Shortcomings:
* Fixes the symptom, not the bug. [1] I think the fix should not do
string replacement, but output the correct HTML in the first place.
(I realize this is the best one can hope for as a 3rd party app, but
if something were to come into core it would have the ability to fix
things properly.)
* Doesn't "fix" the rest of the areas where Django outputs XHTML. Is
it possible?
* Ties various parts of Django to the-thing-that-produces-HTML.
2. Add a new setting, e.g. settings.DOCTYPE, that various parts of
Django and 3rd party apps use to render HTML.
Advantages:
* Simple and straightforward
Shortcomings:
* Yet another setting
* Doesn't allow for template level decisions of doctype by designers
Since I think idea #1 has the best chance of making headway, I've
tried to look at how it might be done. Unfortunately, I don't know
the template system well enough to see how setting {% doctype "html4"
%} might be able to affect other areas of Django. Here was my thought
process the other night...
If Django widgets and other parts of Django always used the Template
system to render HTML, it might be possible to set some global context
variable of the current doctype. But perhaps the reason for not doing
this initially is because each `get_template` call results in a read
from the filesystem (or thread safety?)? In which case, we should
consider fixing #6262, Cache templates. Using Templates everywhere
does inhibit re-use of pieces of Django outside of Django as they
would all now rely on Django's templates.
There's also the option of something like Werkzeug's HTMLBuilder[2]
and their use in Solace widgets[3].
I don't claim to have the answer, but I'm willing to put time and
effort into helping solve this. Thoughts? Other ideas?
Thanks,
Rob
[1] http://www.pointy-stick.com/blog/2007/09/04/fix-bug-not-symptom/
[2] http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/utils.py#L126
[3] http://bitbucket.org/plurk/solace/src/tip/solace/utils/forms.py#cl-294
--~--~-~--~~~---~--~~
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: Proposal: Better HTML4 support
On Sat, Sep 26, 2009 at 2:13 AM, Simon Willison wrote:
> Yes - I looked briefly at how much work was involved in doing this and
> it's not insubstantial, which is why I opted for string replacement
> just to demonstrate the API. I'm confident the exact functionality of
> django-html could be replicated in a less messy way by patching core,
> but it would require quite a bit of refactoring of django.forms.
This is the bit I was hoping we could get to. What would that
refactoring look like, you think? Would it involve making forms use
Templates? Or something else?
> I think the key problem is template filters, which often produce XHTML
> (linebreaksbr for example). This could be solved by allowing template
> filters selective access to the template context, which I'm in favour
> of in the absence of a compelling argument against. This could be done
> in a way that allows existing filters to continue to work - maybe
> something as simple as this:
>
> register.filter('cut', cut, takes_context=True)
>
> Which emulates the register.inclusion_tag API.
We've got django.forms and tags/filters on the plate. How might we
fix something like comments which has templates which write out XHTML
(or other little places which hand code HTML)?
For example, if one includes contrib.comments in their HTML4 website,
it doesn't validate...
http://validator.w3.org/check?uri=http%3A%2F%2Fjacobian.org%2Fwriting%2Fsnakes-on-the-web%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
Ahem. Sorry Jacob!
I'd really hate to see something like this everywhere:
> Really not keen on that - designers should be able to pick their
> doctype, and there are some cases where specific pages of a site (or
> of a reusable app) might need to use a specific doctype - MathML
> output still requires XHTML for example.
I agree.
Simon mentioned how HTML and XHTML could result in Javascript and DOM
differences -- should we be concerned about being too dynamic about
swapping out HTML for XHTML, and vice versa, for fear of breaking
Javascript and CSS that rely on them?
For example, I think the Django admin is fine as XHTML since it isn't
intended to be an included part of your website. But say we were able
to easily set a different doctype that rendered as HTML4. Does that
have the possibility of really breaking things?
> I've somewhat foolishly volunteered for a bunch of 1.2 related hacking
> already (CSRF, logging, signing) but I remain actively interested in
> this, so I'll try to keep an eye on things and see if there's anything
> I can contribute.
If we can come up with something that everyone is happy with, I'm in
for volunteering time to help code it. I'm sure it will be a learning
experience for me as far as Django internals, but I'm willing to put
the effort into it.
Thanks,
Rob
--~--~-~--~~~---~--~~
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: Proposal: Better HTML4 support
On Sat, Sep 26, 2009 at 11:33 AM, Simon Willison
wrote:
> I don't think it would involve form widgets being rendered with
> templates simply because of the performance overhead - even with the
> template caching improvements it's still a lot of work just to output
> an input tag. It might involve some kind of light-weight helper for
> outputting tags though - render_tag('input', {'type': 'text', 'name':
> 'blah'}, xhtml=True) maybe.
For lack of knowing about anything better, I keep falling back to
Werkzeug's HTMLBuilder class[1]. Pulled out and stripped of comments,
it weighs in at 77 lines of code...
Here's a brief Python shell of how it works...
>>> html = HTMLBuilder('html')
>>> html.input(type='text', name='blah', value='"Quote & Ampersand"')
u''
>>> html.select(name='template', id='id_template', *[html.option(v, value=k)
>>> for k, v in dict({1: 'One', 2: 'Two', 3: 'Three'}).iteritems()])
u'OneTwoThree'
I really like how it handles children nicely, as in the select/option
example above.
>>> xhtml = HTMLBuilder('xhtml') # XHTML dialect
>>> xhtml.input(type='text', name='blah', value='"Quote & Ampersand"')
u''
This automatic CDATA escaping in XHTML is also nice:
>>> html.script('var id=document.getElementById("id")')
u'var id=document.getElementById("id")'
>>> xhtml.script('var id=document.getElementById("id")')
u'/**/'
I could see using something like this and making a template tag
wrapper around it like the namespace template tag you mention below.
I *think* that would simplify a lot of what you see in the Django
template widget render code that deals with attributes (e.g.
buildattrs, flattatt), which should make writing widgets and
sublcassing widgets a bit easier.
> The form.as_p stuff works as either HTML or XHTML. It would be nice to
> further emphasise the ease with which people can create their own
> reusable form templates (define them as an includable fragment that
> iterates over the form), and it would be nice if there were more
> finely grained methods for things like accessing the HTML ID of a form
> field. I don't see any reason to templatise those parts in particular
> though - unless someone has smart ideas about how baked in default
> templates could dramatically improve the overall form experience.
I agree with what I think I'm reading here -- a goal being to give
designers more fine grained control over the form and form elements at
the template level.
> That's tricky. There are really only a few tags that actually differ -
> anything that needs to be self closing, which means the following:
>
>
>
>
>
>
>
>
>
>
Also:
> Of these, only meta, link, img, input and br are really common. I can
> think of a few ways of dealing with this, none of them particularly
> enticing:
>
> 1. a {% selfclose %} template tag:
>
>
>
> {% selfclose %} outputs either blank or " /" depending on the doctype.
>
> 2. a {% tag %} tag:
>
> {% tag br %}
>
> Like the {% field %} tag, this could take optional attributes:
>
> {% tag br class="break" %}
>
> 3. {% field %} style tags for all of the self-closing XHTML tags:
>
> {% br %} {% br class="break" %}
> {% hr %}
> {% meta name="dc:author" value="Simon" %}
>
> This option really sucks - that's 9 new template tags polluting our
> default template namespace which do almost nothing. That said, if we
> added template tag namespacing we could at least do {% tag.br %}, {%
> tag.hr %} etc.
>
> They're all pretty horrible, but I think out of those I prefer option
> 1 (maybe with a better, shorter name).
I think you might want both 1 and 3. (1) for those that want finer
control or just don't want to use the underlying HTML wrapper, and (3)
for those that do.
Would it be something to consider adding special case tag, like
comments, to represent the self closing slash depending on current
context's doctype? For example, something like {% / %}?
[1] http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/utils.py#L126
I feel like I'm starting to get a picture in mind for all the pieces
at play here.
Thanks,
Rob
--~--~-~--~~~---~--~~
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: Proposal: Better HTML4 support
On Mon, Sep 28, 2009 at 6:38 AM, Russell Keith-Magee wrote: > By way of greasing the wheels towards trunk: if the outcome of this > mailing list thread was a wiki page that digested all the ideas, > concerns and issues into a single page, it will make the final > approval process much easier. Luke Plant's wiki page on the proposed > CSRF changes [1] is a good model to follow here - I wasn't involved in > the early stages of that discussion, but thanks to that wiki page, I > was able to come up to speed very quickly and see why certain ideas > were rejected. > > [1] http://code.djangoproject.com/wiki/CsrfProtection I don't mind trying to piece a Wiki page together documenting the current conversation. I agree it will make a good pointer for reference and future discussions. -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: Tutorial Refresh
I'd like to propose the addition of a new tutorial that represents a complete website, describing everything from start to finish. This would allow for many more topics to come into play -- things we all deal with at some point in developing websites using Django. This would also allow for those topics to have a concrete central model and not be hypothetical situations. The end result should be source code someone can checkout of a source control repository and run themselves. It would also be nice if the site being developed in the tutorial were available and useful to the community as a whole. To that end I'm also proposing that the site be http://www.djangosnippets.org/, as long as James Bennett is ok with it. The source code is already available and under a BSD license. The site is already well used and important to the community. The model is relatively simple (snippets) with the possibility of a few 3rd party apps for things like ranking of snippets, tagging, registration, Pygments, etc. Django snippets would also benefit from this process by getting an update to Django 1.0 (or newer). I think an outline of the tutorial steps and what should be covered is important to solidify at the outset. That way if someone has a particular interest in, say, caching, they could jump right in and start fleshing out that step. There are some dependencies on early steps, of course. Here's a very rough proposed outline that should be fleshed out more and more detail added to each step on what topic areas to cover. Much of the current tutorial could be "ported" to the appropriate steps... 1. Creating a project - install, runserver, settings 2. Creating an app - app philosophy, INSTALLED_APPS 3. Creating models 4. Enabling the admin 5. Writing urls and views - generic views, custom views 6. Templates 7. Forms 8. Tests 9. 3rd party apps 10. Search 11. Feeds 12. Caching 13. APIs 14. i18n and l10n 15. Deployment What I'd like to know is: * How do people feel about a tutorial that covers a complete site? * How do people feel about that site being Django snippets? * Comments on the proposed outline? Are there any important steps missing? Ordered logically? Feel free to add detail to any step. * Do we cover things not in Django -- like model migrations, search, RESTful APIs -- using 3rd party Django apps? * Would it be possible to do this openly, with easy user comments, like the Django book? Is that software available? Also, if we're going to pull this off we're going to need people to help in a variety of ways. So I'm also curious who might be interested. We'll need: authors to write some sections, reviewers to give feedback, editors to clean up text and bring uniformity to the whole thing, developers to make sure the software the tutorial is describing is coded using best practices and works, a handful of people to drive the process and foster community involvement, etc. Feedback welcome, Rob --~--~-~--~~~---~--~~ 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: Proposal: Tutorial Refresh
I, too, like the idea of a conference site. It fills a void and sounds useful for upcoming conferences. I wasn't too crazy about the blog idea, and was convinced away from the snippets idea. So shall we call it a conference site and move on? :) For a nice reference implementation, I'd like to point to the software running the Open Source Bridge website. It's developed in Ruby on Rails and is hosted on Github: http://github.com/igal/openconferenceware I attended the Open Source Bridge conference and thought the website was one of the most well done of any conference I've been to -- from initial call for talks to attending and checking the schedule. The website is here: http://opensourcebridge.org/ If the intention is that this will be used for the DjangoCons, we would need input from those that run DjangoCon. For example, I really liked the open submission process and the fact that the conference took everyone's comments (which were private) into consideration when picking the subset of talks. But I can imagine that's not for everyone. Thanks, Rob --~--~-~--~~~---~--~~ 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: Proposal: Tutorial Refresh
On Sat, Oct 10, 2009 at 6:04 AM, Ned Batchelder wrote: > My strong feeling is that these two goals will quickly become impossible to > reconcile. I think the idea of a conference site is a good one (everyone > will understand the problem domain, lots of interesting avenues to explore, > it's not yet-another-blog), but aiming for it to be the actual site used for > DjangoCon will not work in the long run. > > The tutorial is extremely important. It will be the first part of the docs > read by 98% of new users. Don't complicate it by tying it to DjangoCon. > This thread has already seen requests for features that will be great for > real use, but would probably be too much to put into a tutorial. While it > would be very cool to have the two sites be just one site, I think it will > either create an overgrown underexplained tutorial as DjangoCon adds > features needed for a real-world conference site, or a simplistic toy > DjangoCon site because the tutorial needs to ensure that everything is > clean, understandable, and accompanied by clear prose. > > Why not serve just one master well, and have the tutorial be purely about > exposition and pedagogy? After more thought I agree with Ned. Not only will the goals be hard to reconcile, I think we're encroaching the turf of the DjangoCon conference organizers. I also think the data model will be sufficiently complex and lead to a lot of hand waving in the tutorial. Ideally, I think a good candidate for a website/tutorial will have the following components: * The goal and domain should be simple to grasp and explain in a few sentences. * Have one main app that is the central focus on the website * Have one main model, with several peripheral models that could be introduced as the tutorial progresses. * Be complex enough to require many areas of Django (e.g. Forms, Aggregates, Caching, etc) I'll have to ponder further on what fulfills these requirements. One thought I had was to use the existing poll tutorial, but expand it to be a site on its own. Something along the lines of http://strawpollnow.com/ but not necessarily with the Twitter integration? Thanks, Rob --~--~-~--~~~---~--~~ 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: The this-needs-to-be-in-django angst
On Wed, Oct 21, 2009 at 12:22 PM, mrts wrote: > A DVCS mm-tree > -- > > Quoting > http://en.wikipedia.org/wiki/Andrew_Morton_(computer_programmer) > > "He currently maintains a patchset known as the mm-tree, > which contains not yet sufficiently tested patches that > might later be accepted into the official Linux tree." > > I.e. there would be a DVCS branch (avoiding the f-word now) > maintained either by a core dev or a designated community > member that would accept patches more liberally -- but still > only patches that are up to Django standards, i.e. tests and > docs remain mandatory. > > This will probably be most effective in context of the bug > days, otherwise the management overhead may be too big. > > Also, that branch would have a few buildbots running tests > on it. Another benefit of a merge-queue branch is testing and verifying that multiple patches play well together before actually hitting trunk. For multiple big branches this is even more important. -Rob --~--~-~--~~~---~--~~ 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: Public method for getting model field names in order of definition
On Wed, Oct 21, 2009 at 6:38 AM, David Chandek-Stark
wrote:
>
> The values_list() query set method is useful for dumping data to CSV,
> etc. However, I find that I often want to use it without specifying
> the field names (to get them all) and yet also include the field names
> as the first row in my data export. There is no "public" method for
> getting all the names of a model's fields in the order of definition.
> Model._meta.get_all_field_names() returns a sorted list, and one has
> to read the source code to discover that one should (probably) use the
> "attname" attribute of a field for its name rather than the "name"
> attribute. The ValuesQuerySet superclass of ValuesListQuerySet by
> default sets its field names with:
>
> [f.attname for f in self.model._meta.fields]
>
> So, my question is: Do folks think that it would be good to have a
> public method for getting the field names in order of definition?
I do, and have another use case in mind...
For example, let's say you have a Profile model and you have a profile
edit view which uses a ModelForm. In the edit template you can simply
output the {{ form }} or iterate over the form:
{% for field in form %}
# output field
{% endfor %}
But if you wanted to redisplay that information back to the user in a
read-only form, there is no iterative way to do so (as far as I know).
Instead you must specifically "hard code" each field:
Field 1
{{ profile.field1 }}
This doesn't solve your use case, but I'd like to see some sort of
ModelDisplay, which mimics ModelForm, and can be used in such a way to
either specify select fields or exclude fields:
class ProfileDisplay(ModelDisplay):
class Meta:
model = Profile
exclude = ('user',)
You could then pass this to your template and iterate over it:
{% for field in profile_display %}
{{ field.field_name }}
{{ field.value }}
{% endfor %}
In the past I've discovered the model_to_dict in
django/forms/models.py that could be used for this if only it used a
SortedDict instead of a plain dict. With this minor change...
@@ -121,7 +121,7 @@ def model_to_dict(instance, fields=None, exclude=None):
# avoid a circular import
from django.db.models.fields.related import ManyToManyField, OneToOneField
opts = instance._meta
-data = {}
+data = SortedDict()
for f in opts.fields + opts.many_to_many:
if not f.editable:
continue
You could then, in your view, do:
profile_display = model_to_dict(profile_obj, exclude=('id', 'user'))
And in the template, do:
{% for field_name, value in profile_display.items %}
{{ field_name }}
{{ value }}
{% endfor %}
Which I think would be a nice shortcut for template creators and also
reduces code change as you adapt your models.
All that said, I'm not sure if I'd propose this change for this
purpose... or if we did the method might better live somewhere else.
The model_to_dict method is used specifically for Forms as the
docstring cites: Returns a dict containing the data in ``instance``
suitable for passing as a Form's ``initial`` keyword argument.
Is this a use case others could use?
-Rob
--
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=.
Re: Why not datetime.utcnow() in auto_now/auto_now_add
On Tue, Nov 24, 2009 at 3:36 PM, Russell Keith-Magee wrote: > > Time zone handling is definitely something that Django could handle > better, but simply switching to UTC for certain functions isn't the > solution. > I like the solution proposed on ticket 10587: http://code.djangoproject.com/ticket/10587 Basically, it proposes that timezones are handled analogous to how Unicode is handled -- that is, everything within Django boundaries is treated as UTC, with timezone conversions happening on input and output, but never within Django and always stored as UTC in the database. Ticket 10587 was closed as a duplicate of 2626, but I think 10587 has the better description and proposal in it. -Rob -- 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.
Re: admin javacripts
I've battled many of these same issues when working on the debug toolbar... it needs to work the same in any environment it gets loaded into and, as such, has slightly different requirements put on it. It is seeming the admin is heading the same direction to some degree. While certain parts of the admin are (or will be) using jQuery (widgets, etc.) there's the potential that someone has skinned the admin in such a way that they need an admin with Prototype, for example, to function. That's leading me to think admin widgets and plugins need this same level of encapsulation. On the ticket I posted a bit of skeleton javascript code that shows how to completely encapsulate both jQuery and widget code into a closure. It's seeming like a good idea to take this approach for all widgets and plugins that are developed for Django. It goes the extra step of checking a minimum version of a pre-existing jQuery and passes in a boolean whether or not jQuery was loaded from Django or provided via custom JS by the developer. I don't know if those are needed exactly, but it's there. This is the basic structure I'm now using for the debug toolbar and it's working well. Happy to help in some way on this if I can. -Rob On Thu, Feb 18, 2010 at 2:20 AM, Ales Zoulek wrote: > Hello, > there a ticket about jQuery in admin that breaks any site-included jQueries > and there's no easy/clean way to prevent it. > http://code.djangoproject.com/ticket/12882 > > Let's see a bigger picture there. > To my knowledge, admin has two ways how to include custom JS. One template > based second py-api based: > 1] base_site.html (or other top level template) > 2] ModelAdmin.Media class > First forces user to copy at least part of the html code to his own project > templates. Second allows only per-model javascripts. (Please note that none > of them solves the bug reported in a ticket.) > > > I'd see to possible ways how to fix the ticket. > - Quick and easy: > For some reason, admin uses the ModelAdmin.media to contruct it's own list > of javascripts. Isn't it safe to say that admin has a fixed set of JS libs > it uses and include them on all pages in base.html? > It seems to me safer and more straight-forward behaviour then including > "some.js" if ModelAdmin has some actions, and "some-other-lib.js" if > ModelAdmin.opts.get_ordered_objects(). It makes a bit difficuilt to prevent > javasript name conflicts in site-wide javascripts. I'd propose > that ModelAdmin.media would serve only for apps, not to admin itself and all > admin's JSs would be included in base.html. > The down part is ofcourse thirtd party apps, that can cause some JS > collisions, but its at least easier to control which app I install and what > templates/js it uses or overwrites, and they don't "magicaly" intrude their > js in every change list page. > > - Not so quick and definitely more controversial > What I'd really like is to have some means how to affect admin's behaviour > per-project (not only by redefining admin templates). > That would include overriding it's JS inclusion paths, but other things as > well (global actions, extra context, items per page in change list, etc...) > > > What are your thoughts about that? > > > Regards, > Ales > -- > Ales Zoulek > +420 604 332 515 > Jabber: ales.zou...@gmail.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-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. > -- -Rob -- 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.
Re: admin javacripts
On Fri, Feb 19, 2010 at 8:58 AM, Luke Plant wrote: > IMO, using 'library agnostic' javascript in the admin will mean we > just end up implementing our own library, which will end up being an > ad hoc, informally-specified, bug-ridden, slow implementation of half > of jQuery/dojo/etc, and even less likely to be able to interop with > other libraries. I agree. And now that jQuery is in the admin, it seems like there's a decision point... 1) Do we put jQuery in base.html and have Django's widgets and plugins assume it will be there? * Benefits: Javascript admin customizations are simpler and can use the jQuery already on the page. * Trade off: If someone wants to override base.html and put in mootools, e.g., Django's widgets break. 2) Or do we put jQuery in each widget's media setting and encapsulate both jQuery and the plugin code in a closure? Which seems like where Django has been heading by default and the one I would advocate. * Benefit: Users can override base.html and add their own JS library of choice, even if it's jQuery for easy development or things outside of widgets. * Trade off: A bit trickier to develop admin widgets. But perhaps this could be worked on -- something like jQuery UI's widget factory methods? -Rob -- 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.
Re: EmailMessage mangles body text
On Tue, Apr 27, 2010 at 6:38 PM, Leo wrote: > Digging deep into Python's innards reveals that this is a somewhat > esoteric protection in case you're writing out Unix mailbox files. The > specific issue is here: > http://docs.python.org/release/2.6.2/library/email.generator.html#email.generator.Generator > and involves the mangle_from_ flag. > > The hugely more likely case is that if you're using Django's > EmailMessage class you're sending emails rather than writing Unix > mailbox files and are running into this bug that way. Wouldn't these e-mails end up on other servers that might save the message in a Unix mailbox format? And if so, wouldn't removing the ">" from the "From" cause problems? -Rob -- 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.
Re: FK Autocomplete Widget [GSoC '09 Admin UI Improvements]
If I recall correctly, there's another branch on the that project that was refactoring the autocomplete widgets so that there were essentially 2 widgets: A widget intended to be used in your own Django code, and an admin widget that was a subclass for use in the admin. To me that would be a nice feature addition. It does, however, bring into question the fact that a widget, intending to be used on the public side, would depend on jQuery for its UI. Is Django ready to go there? Or would an admin-only autocomplete widget be preferred? Also, at the time, many of the jQuery autocomplete widgets were in a state of flux or had some warts. Our (Jannis and my) idea at the time was to write our own from scratch, custom and optimized for Django. That looks to be about a year ago so the state of things is probably much different today. (Or not?) -Rob On Wed, Jun 2, 2010 at 7:13 AM, Sergej dergatsjev eecho wrote: > Current Admin Extensions > > ForeignKeyAutocompleteAdmin - ForeignKeyAutocompleteAdmin will enable > the admin app to show ForeignKey fields with an search input field. > The search field is rendered by the ForeignKeySearchInput form widget > and uses jQuery to do configureable autocompletion. > > http://code.google.com/p/django-command-extensions/ > > > 2010/6/2 bydesign : >> I second the vote to add the GSoC '09 Admin UI foreign key >> autocomplete! It's actually somewhat embarrassing that this >> functionality hasn't made it in yet. Foreign keys in the admin >> interface become unusable if you have more than 50 or so rows in the >> table. I hope that since this code has already been written and >> tested, it can be included very soon! >> >> >> On Jun 1, 9:30 am, Russell Keith-Magee >> wrote: >>> On Thu, May 27, 2010 at 8:26 PM, Philipp Metzler wrote: >>> > hello, >>> >>> > i'm looking for exactely the same solution for an "Ajax foreign key >>> > filter in the Django admin interface" and hoped it would be integrated >>> > into the admin interface. I think it should be standard behaviour and >>> > could be configurable in the admin.py Is the development of the admin >>> > interface going in that direction or is it not planned at all? >>> >>> We're at the start of a development cycle, so the plans for the next >>> release haven't been finalised yet (beyond the broad guideline that it >>> will be a feature-light, bugfix heavy release). If this is an area >>> where you would like to see improvements, feel free to make a specific >>> proposal (preferably one accompanied by sample code :-) >>> >>> Yours, >>> Russ Magee %-) >> >> -- >> 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. >> >> > > -- > 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. > > -- -Rob -- 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.
Re: db_index not creating indexes with syncdb
Russell Keith-Magee wrote: > You are correct (and it's not just with MySQL). This is a bug born of > the way that syncdb installs applications. For some reason, it doesn't > defer to install - it duplicates the install logic, but doesn't include > indexes. > > I intend to refactor this code when I get into the installation of > fixtures for the testing framework (#2333). However, if you want to > ensure that this bug doesn't get missed, open a new ticket (do a quick > search first to check that it isn't already logged). There's a related bug already opened for it here: http://code.djangoproject.com/ticket/1828 Thanks, Rob --~--~-~--~~~---~--~~ 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: authentication data
patrickk wrote: > 2. when using a custom manipulator for letting the user change his > personal values (first name, last name, address, zip_code ...), I > have to change 2 different tables (user and userprofile). that doesn > ´t seem to be clean ... ??? Can you not put first name, last name, and email in your own user_profile table and use those fields instead of the default Django fields? Leave the Django fields blank and always work with your own fields? --~--~-~--~~~---~--~~ 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: Are non-critical patches getting enough attention?
I've been slowly trying to work my way into helping out with Django, but mostly at the outset I'm reading all the docs, reading the source, and trying to figure out how it all ticks. Some areas are easier to get than others. But as an interested person who'd love to contribute, what's the best approach? The "LittleEasyImprovements" all seem to be taken. I think it would be cool for a dev to write some docs on ways to help in small ways. The triage helpers is a nice idea. The Linux kernel has their "Janitors" (http://janitor.kernelnewbies.org/). Even docs on how you search for "low hanging fruit" would be cool -- if "LittleEasyImprovements" isn't up to date, this could be a doc on how to find those. Just some ideas from someone interested and wanting to help (and who has a full-time paying job). Thanks, Rob --~--~-~--~~~---~--~~ 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: Proposal: Forms and BoundForms
Joseph Kocherhans wrote:
>
> form = ContactForm()
> if request.method == POST and form.bind(request.POST):
> send_email_and_redirect()
> return render_to_response('email_form.html', {'form':form})
>
> Assumptions: form.bind(data) does *not* return a BoundForm. bind does
> the validation and probably populates form.errors or .errors() or
> whatever. bind returns True or False depending on whether validation
> succeeded or not. bind does not short circuit on the first error.
>
> Validation happens only once, in the bind call. It's not entirely
> obvious that a method called bind would return a boolean depending on
> the success of validation, but examples and docs should clear that up
> that I think. Maybe this is being too clever to save a couple of lines
> or a few milliseconds though.
(I'm not an official "dev" so I hope it's not considered inappropriate
of me to provide my feedback.)
Instead of the assumption that bind() validates, why not have an
is_valid() method that assumes binding of the Form. To me this is a
more appropriate assumption since you have to bind the form to validate
it. And it leaves some flexibility open so you can bind forms and not
yet validate -- say if you want to bind and do some other form actions
and then validate.
Example...
form = ShoppingForm()
if request.method == POST and form.is_valid(request.POST):
...
Or...
form = ShoppingForm()
if request.method == POST:
form.bind(request.POST)
if form.billing_same_as_shipping == True:
# Copy billing info to shipping
form.shipping = form.billing
if form.is_valid():
...
The access methods for "form.shipping" probably aren't appropriate, but
just making a use case for extra manipulation of form data before
validation.
-Rob
--~--~-~--~~~---~--~~
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: Proposal: Forms and BoundForms
I'd like to see some flexibility to output HTML4 as opposed to XHTML (or whatever flavor comes along next). Currently in 0.95 it looks like all the render() calls on the various "generic widgets" output XHTML form elements. I've been pretty much convinced not to use XHTML by Ian Hickson (at least not yet): http://www.hixie.ch/advocacy/xhtml Of course, all this is based on my assumption that something like this: is invalid as HTML4, but I haven't verified that HTML4 can't have self closing tags. -Rob --~--~-~--~~~---~--~~ 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: schema-evolution: status?
Matthew Flanagan wrote: > cd django_tmp_src > svn merge -r 3332:HEAD http://code.djangoproject.com/svn/django/trunk > > [resolve and conflicts and test your code] > svn co -m 'merged latest changes from trunk' I think that should be: svn ci -m 'merged latest changes from trunk' After you resolve conflicts and things look good you check in your code. -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Comments system
The Wiki page on the API Stability says this about the comment system: > The comments framework, which is yet undocumented, will likely get a complete > rewrite > before Django 1.0. Even if the change isn't quite that drastic, there will at > least be > moderate changes. Are there goals or docs about what this might become? There seem to be enough people using the comments systems that maybe people could work on a patch (or at least get started in the right direction) if there were some goals and ideas on what's considered broken currently. I've personally hacked apart the FreeComment system. At work I'm building an internal tool and will need to hack apart the Comment system. So I've got a little bit of a vested interested in knowing where this is going and may even be able to help out a little. Being that the Forms and Manipulators code is going to be overhauled, and the comments depend on that, that may be a dependency before any work happens on Comments. Even so, some ideas on what people want out of a generic comments solution would be interesting. Personally, I'd like to see: * Combine Comment and FreeComment and by configuration allow the ability to post anonymously. * Let ratings and karma be more modular so these can be enabled/disabled and not dependent on the other (for example, I think currently if you have ratings you also have to submit a comment. Maybe this simply means pulling ratings out completely into its own app.) Thanks, Rob --~--~-~--~~~---~--~~ 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: Comments system
James Bennett wrote: > On 10/26/06, Rob Hudson <[EMAIL PROTECTED]> wrote: >> Are there goals or docs about what this might become? There seem to be >> enough people using the comments systems that maybe people could work >> on a patch (or at least get started in the right direction) if there >> were some goals and ideas on what's considered broken currently. > > IIRC, one of the big (and, to me, most interesting) suggestions > involved changing the system so that you could write a model which > conformed to a particular interface (e.g., FK to user, FK to > contenttype and an object_id, plus maybe a couple methods), then drop > it into a setting and have it be "the comment model". The ones we ship > now should still be bundled, of course, and used as the defaults, but > that would add a huge amount of flexibility to the system. I'm having trouble visualizing how that would work. I searched the list and the tickets for more info but didn't find anything. Is the gist of the idea that you'd set up the model and a few methods and the bulk of the work would get wrapped around that? Thanks, Rob --~--~-~--~~~---~--~~ 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: Call for comment: Forms/manipulator replacement, take 1
> I hacked on the forms thing a bit more on a 3-hour plane ride today
> and came to the same conclusion. I've attached the newest version of
> this file (gee, progressing like this is going to get unwieldy unless
> I check this into SVN), which has changed Widget.render() to take the
> name and value. I've also made some other changes, mostly in
> additional unit tests that show off some of the cool features.
For those of us not using XHTML would it be possible to add a flag to
output valid HTML?
I'm curious if something like this might be a useful way to override
the output...
>>> w = TextInput()
>>> w.template = template.Template("")
>>> w.render('email', '')
u''
Though this seems like overkill if you can already manipulate all the
attributes of the input tag.
-Rob
--~--~-~--~~~---~--~~
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: What's going on with all these branches?
I think it would be a good idea to have a bug-squash/testing day on IRC for certain branches. Maybe the developers of those branches let someone (?) know they'd like some testing. A day is picked and that's the testing day. Try to raise awareness on the mailing lists and that IRC will be the place to communicate. Right now as an outsider it's not clear where to find out the status or to know that the developers are looking for end-user testing and what specific areas to watch out for. Putting a certain branch on a schedule with this info plus having IRC to communicate would be good. The goals and outcome would be bugfixes and a yes/no decision on whether it's ready to merge with trunk. -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
content types
Would there be a way to do something like this: If contrib.contenttypes are in settings.INSTALLED_APPS: Add to models.Model a method: get_content_type that returns the ContentType object?. That way, any model I have will have that method available to easily and quickly get its content type. I've been playing with apps that relate to content types more and this seems like a useful thing to have. I tried adding a method to my model along the lines of this: def get_content_type(self): cm = ContentTypeManager() return cm.get_for_model(self) But that failed: >>> from innovate.innovation.models import Innovation >>> i = Innovation.objects.get(id=1) >>> i.get_content_type() Traceback (most recent call last): File "", line 1, in ? File "/Users/rhudson/sandbox/innovate/../innovate/innovation/models.py", line 37, in get_content_type return cm.get_for_model(self) File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/django/contrib/contenttypes/models.py", line 13, in get_for_model ct, created = self.model._default_manager.get_or_create(app_label=opts.app_label, AttributeError: 'NoneType' object has no attribute '_default_manager' So I ended up hard coding it, which is ok, I suppose: def get_content_type(self): return ContentType.objects.get(app_label__exact="innovation", model__exact="innovation") It just seems like a more introspective way to do this could come in handy. -Rob --~--~-~--~~~---~--~~ 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: content types
Jacob Kaplan-Moss wrote: > Try this:: > > from innovate.innovation.models import Innovation > from django.contrib.contenttypes.models import ContentType > > i = Innovation.objects.get(id=1) > ct = ContentType.objects.get_for_model(i) Yeah, that's not so hard. I updated my method to this and it worked just fine. def get_content_type(self): return ContentType.objects.get_for_model(self) Thanks. Besides the suggestion that this might be a good inclusion to models.Model, I guess this should have gone to django-users. -Rob --~--~-~--~~~---~--~~ 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: Branch Merges?
Jay Parlar wrote: > The core devs tell people all the time that it's generally safe to run Django > off the trunk I think this is a self-imposed limitation to allowing a branch that's close to be merged to trunk to get more testers. For myself, I'd much rather see some broken things on trunk on occasion if that means it is easier to develop and move Django forward. I'm not involved in a lot of open source projects, but at least for Mozilla, this seems how they operate. Things get broken on trunk as they merge in new features. Eventually, bugs get worked out, and they do a code freeze prior to a release to make the release as stable as possible. Would Django consider adopting a model like that? --~--~-~--~~~---~--~~ 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: Branch Merges?
Adrian Holovaty wrote: > That's exactly what we're using the branches for: Things get broken on > the branches as branch owner merge in new features. Eventually, bugs > get worked out, and they do a code freeze prior to the merge to make > the branch as stable as possible. I suppose the disadvantage to this is getting users to test branches. > The self-imposed limitation to making trunk usable at all times is one > of the things I particularly like about our arrangement. It's mostly > for developer convenience, so fans of the latest-and-greatest can > simply "svn update" their Django codebase to get the latest, with > minimal breakage. It's all the convenience of daily builds with none > of the upgrade overhead. I admit I like it too. What about a hybrid approach? Maybe be less strict about how stable a branch is if it's "close enough". Then merge with trunk to get extra testers and bug fixes. For me, I develop on my local machine against trunk. If a branch merge comes down and something breaks, I'd likely end up looking at recent commits and post a message to django-users, or file a bug. Instant testing and bug reports. :) Maybe this is the current model but it feels like a rock solid branch is wanted before a merge to trunk happens. That requires testing on branches which is extra work and an apparent hindrance. -Rob --~--~-~--~~~---~--~~ 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: Branch Merges?
Michael Radziej wrote: > Let's have a branch of the month, announced on devel and users. The > branch is then frozen, merged with trunk, and will be merged at a fixed > date into trunk if no critical and unfixable bugs are found. This would > encourage at least me to check this branch out and test it well before > the merge ;-) I like this idea too. Maybe even schedule a bug day (or few) on IRC over the course of the month to get more feedback on a particular branch that's schedule to be merged. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
inline_models as a replacement for edit_inline?
I stumbled across this ticket with patch a couple months ago. I thought of it recently and wanted to bring it to the attention of the developers. I like the idea and it looks like it simplifies the edit_line stuff a lot... http://code.djangoproject.com/ticket/2248 --~--~-~--~~~---~--~~ 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: inline_models as a replacement for edit_inline?
Aidas Bendoraitis wrote: > Not a bad change, but much more important, in my opinion, would be to > have an ability to set the fields of inline edited models according > the formatting set in fields list/tuple; with all the features as > collapsible groups of fields, placing fields next to each other > horizontally, setting HORIZONTAL style for many-to-many selection > fields and so on. That would be cool. What I like about this is it pulls the edit_inline stuff out of the models themselves and puts them in the Admin inner class. It's cleaner to me. Doing it how you suggest sounds like it would accomplish the same thing. --~--~-~--~~~---~--~~ 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: How to run all django tests?
I was just playing with trying to run the tests this morning as well. Doing "python runtests.py" in the django/tests directory gives me an error about the DJANGO_SETTINGS_MODULE. I couldn't figure out what needed to be in my environment setting to get the tests to work. Searching Google didn't turn up anything either. How do you run the tests? --~--~-~--~~~---~--~~ 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
James Bennett wrote: > So I've been poking around in the newforms code, and it appears that > the pre-defined widgets will be producing XHTML-style output. I had the same thought but I wrote a quick test with an HTML 4 strict doc-type, put an input tag in it like this: , and it was still valid. I'd like to see agnostic HTML from Django too, but if it isn't producing anything that breaks HTML 4, I'm happy. One of my worries is that the W3C, from what I've read, is going to re-invigorate HTML and work on HTML5 as well as XHTML2. If these two diverge enough, Django may need support for both. Somewhere I think I suggested the possibility of passing in a template string to the forms on how they should render, but the only purpose of this would be to remove the "/", and requires knowledge of the local variables. Last I looked the forms stuff is pretty flexible with adding attributes (ie: class names) and things. So there's not a lot of benefit doing that. -Rob --~--~-~--~~~---~--~~ 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
This looks pretty cool. I'm excited by the new forms development and hope to play with some of it soon. It seems a little out of place to me to instantiate an object in urls.py: (r'^post/$', MyFormPreview(MyForm)), (There was some thread talking about urls.py becoming more of a "controller", but I never followed up on understanding that idea fully.) -Rob --~--~-~--~~~---~--~~ 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 20061207.0851, Adrian Holovaty said ... > This would be a great addition. Rather than requiring sessions, what > do you think of passing intermediate form data in hidden fields? It's > simpler, it wouldn't require cookies and I can't immediately think of > any downsides to the approach. One downside: If the user closes their browser (or the OS crashes, or any number of other things), if the state so far is in sessions tied to a cookie, they can jump to where they left off. If all state is in the forms and not stored anywhere, they cannot. Depending on the situation, that could be a downside or that could be intentional and wanted. -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django t-shirts?
There was a discussion a long time ago about Django t-shirts (at OSCON?). My question for the core devs is: Why not set up a quick Cafe Press site for a couple simple t-shirts and use the money to help fund development? Maybe put up bounties for some bugs or features? Or simply split the proceeds each month? I was at Jacob's site (which is pretty cool, BTW, though it's pretty brave to automatically put all your Google searches online!) and got a kick out of some of the Django things at the bottom: * If I had a django, I'd django in the morning * All your django are belong to use * django bells, django bells * Keep on django in the free world Where "django" is the Django logo. I'm just saying... I want a Django t-shirt. :) Just 2-cents. -Rob --~--~-~--~~~---~--~~ 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
Isn't the session a natural place to store these kinds of things? Is there a reason for the avoidance of sessions? Are they buggy? Do they require some sort of over-head people are trying to avoid? Just curious, Rob On 20061211.1152, Kevin said ... > > I like the idea of storing an encoded-pickled version of the form data > in a hidden field. I'm concerned about privacy implications with > sharing that data with the client. What about encrypting the contents > too? The server could have a private key that it encrypts the > serialized form data and decrypts on submission. --~--~-~--~~~---~--~~ 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: Thinking out loud: move auth.Messages into the sessions app?
I agree that it's more intuitive to tie messages to sessions. I remember reading many articles on PHP sessions and about session hijacking, etc. Has Django's sessions been looked at from this perspective or can Django's sessions have similar issues? Some reference material by Chris Shifflett, one of the leading security guys working on PHP: The Truth about Sessions: http://shiflett.org/articles/the-truth-about-sessions Session Fixation: http://shiflett.org/articles/security-corner-feb2004 Session Hijacking: http://shiflett.org/articles/security-corner-aug2004 In one of those articles, he describes the "impersonation" scenario, which is what I wonder if Jeremy is referring to: 1. Good Guy visits http://www.example.org/ and logs in 2. The example.org Web site sets a cookie, sessionid=12345 3. Bad Guy visits http://www.example.org/ and presents a cookie, sessionid=12345 4. The example.org Web site mistakenly believes that Bad Guy is in fact Good Guy Looking at the Django code, the session_key seems to be quite random using the settings.SECRET_KEY as salt. Could the Django session also add in checks against impersonation, which it doesn't appear to do currently? For example, if the sessionid cookie was issued from a certain IP address, it must come back from the same IP? Or if extra HTTP headers are present they must also be present on subsequent requests (eg: the User-Agent string)? These can be combined so sessions use everything available as a fingerprint that is hashed, as suggested in one of the articles and that hash must match on every request? It looks like there is some tamper checking in the sessions code but I don't quite understand what it's doing on first glance. This code checks that they are the same string? pickled, tamper_check = encoded_data[:-32], encoded_data[-32:] if md5.new(pickled + settings.SECRET_KEY).hexdigest() != tamper_check: from django.core.exceptions import SuspiciousOperation raise SuspiciousOperation, "User tampered with session cookie." He also raises some points on why it might be good to provide an API to the developer to regenerate IDs, or to regenerate a new sessionid in certain scenarios. This is something the model currently doesn't have that might also be useful. In another thread I was asking why it seemed some people were avoiding sessions. Is it security related? Or simply that it requires cookies? Or something else? I'm going to need to rely on sessions on a planned site in the future, so I'm curious why some people avoid sessions in case there's something I don't know about. :) -Rob --~--~-~--~~~---~--~~ 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: Thinking out loud: move auth.Messages into the sessions app?
Jeremy Dunck wrote: > But I agree session hijacking is a concern, though totally unrelated > to the discussion of whether to move messages to sessions. :) Yeah, I kind of got off topic. My apologies. Maybe I should post the same message in a new thread... I think session security is important and I'd be happy to help toughen it up if it isn't already. --~--~-~--~~~---~--~~ 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: Thinking out loud: move auth.Messages into the sessions app?
It looks like these same articles have been checked against Django's session code in this bug: http://code.djangoproject.com/ticket/362 Cool. :) -Rob On 20061212.1819, Rob Hudson said ... > Yeah, I kind of got off topic. My apologies. Maybe I should post the > same message in a new thread... I think session security is important > and I'd be happy to help toughen it up if it isn't already. --~--~-~--~~~---~--~~ 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: Session security (was Re: Thinking out loud)
Benjamin Slavin wrote: > Django does use an algorithm that generates difficult-to-guess session > IDs; however, no current implementation of sessions (by anyone) is > completely safe. I've verified this, actually, with WebScarab, retrieving 1000 consecutive session ids and visualizing them on a plot of id vs time. It was pretty scattered, which is good. I can post the image if anyone would like to see. I did this against Django 0.95. > I haven't seen any proposals for improved session security that are > effective, not easily overcome, and work with upstream proxies. I'm starting to see that this is the case after reading "Session Management" at the OWASP site: http://www.owasp.org/index.php/Session_Management > > He also raises some points on why it might be good to provide an API to > > the developer to regenerate IDs, or to regenerate a new sessionid in > > certain scenarios. > > I agree that this would be a valuable addition. Perhaps you could > submit a patch... if you're not comfortable doing that, perhaps > someone else will. I'd be happy to attempt it. In looking at the code it seems like you could call the SessionManager's get_new_session_key. But I'm not sure what that would look like at the view level where I think it would be most useful. Other improvements to sessions I can think of (and maybe there are ways to do this already): * Add in a last authenticated date stamp to the model so developers can re-authenticate after a certain period of time if a user tries to access sensitive data. I see this a lot on sites where you are still logged in, but if you want to do anything significant you a required to re-authenticate if it has been more than a specified time since last authentication. * An auto purge algorithm that clears expired sessions from the django_session table. I'm thinking something along the lines of PHP's garbage collection settings[1] so one can specify a probability that the session garbage collection routine is called. For low traffic sites you may want a 1 in 20 chance. For high traffic sites you may want a 1 in 1000 request chance. It could be something like: # A tuple signifying an X in Y chance as (X, Y) settings.SESSION_CLEANUP_PROBABILITY = (1, 20) Then the session code would be something like: def trigger_cleanup(): numerator, denominator = settings.SESSION_CLEANUP_PROBABILITY return random.randint(1, denominator) <= numerator if trigger_cleanup(): # call session cleanup code [1] http://www.php.net/manual/en/ref.session.php#ini.session.gc-divisor --~--~-~--~~~---~--~~ 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: Session security (was Re: Thinking out loud)
* Benjamin Slavin ([EMAIL PROTECTED]) wrote: > The get_new_session_key method would probably be a good place to > start, though I have little familiarity with the interface to the > session middleware. I'm swamped right now, so I'll look into it in > the next few days. If you need any assistance, please let me know. I'll try to play around with it some more, if even just for the learning experience. > > * An auto purge algorithm that clears expired sessions > > +1 on the idea / +0 on the implementation > > I've never liked the idea of randomly slowing down requests to perform > housekeeping tasks. It's probably acceptable in low-volume sites, but > for high-traffic sites with a cluster of web servers a dedicated > process more sense to me. > > I think auto purge would need further discussion to figure out the > best solution. To go with the 80/20 rule, I'd imagine that for 80% of Django developers something like this would work pretty well and be useful. If you can disable it for those other cases where you do have a cluster of web servers, would that be good enough? Plus, aren't we talking about a 10th of a second or less to purge the table? It is a good point that if you have 5 web servers fronting a single database backend and each has their own probabilities of running session GC, that's not optimal. Is there a way to make this happen *after* all the content was sent to the user and the HTML tag closed? -Rob --~--~-~--~~~---~--~~ 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: Session security (was Re: Thinking out loud)
Michael Radziej wrote: > > To go with the 80/20 rule, I'd imagine that for 80% of Django developers > > something like this would work pretty well and be useful. [...] > > I don't think so. > > Isn't session cleanup a natural candidate for a cron job (and > whatever is the equivalent in the Microsoft world)? I don't quite > get the advantage of doing it inside the http request handlers. I submitted a patch to the session docs to (http://code.djangoproject.com/ticket/3137) adding in some language that the sessions don't automatically purge expired sessions. At the least it should be in the documentation that this does or doesn't happen and possibly point out the example "daily_clean.py" script as an example of how to purge expired sessions if one wants to. I've set up a few sites with Django and never really thought much about sessions without that notice. Now that I know, I'll go back and add in the cron job. I like the idea to optionally purge expired sessions. The only benefit I see of putting it in with a request is that it doesn't need an external script to do cleanup which may or may not be forgotten about. I'm used to PHP, which does this automatically, and don't know much about how other frameworks handle session cleanup. I'm curious, though... If you do have a high traffic site and your session database fills up, aren't you then more likely to produce an already existing session key. Each one of those requires an extra database call to check for previous existence. The key space is huge, though. Something like 36^40? In these bug comments, hugo said they produce 1 million session keys with very few repeats (http://code.djangoproject.com/ticket/1180). So this probably shouldn't be a worry, but I imagine a popular site running for years on end with little maintenance and the session key space shrinking. --~--~-~--~~~---~--~~ 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: [Proposal]newforms render can use subtemplate
limodou wrote: > I saw that newforms has meny output methods, just like: as_table, > as_p, as_ul, etc, and someone also want to add as_dl. And I also saw > that the output is hardcoded in the source code. In my personal > woodlog project, I made an easyform app, and I can render a form with > a subtemplate, so user can change these templates, and this will make > the representation is separated from the soure code. So I think > newforms can also support this appoach. > > Just a suggestion. I like this idea because it also allows the user the choice of HTML4 or XHTML as well. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
login_required decorator and redirect_to
I've got a particular case that I wonder if it is worth submitting a
patch for...
I do not have an /accounts/profile/ URL and for the site I'm building
it doesn't make sense to have a profile page. But I do need
login/logout functionality and am using django.contrib.auth. I'm also
providing "Login" and "Logout" links in the navigation of the site.
When the user clicks on a URL who's view is decorated by
login_required, they get sent to the login page and the hidden "next"
form field is populated correctly. No problems here.
But, if they click on the login link directly, "next" is empty, and so
it defaults to /accounts/profile/.
What I'd like to do is create a patch that allows one to specify the
default redirect_to field when next is empty so I can override the
/accounts/profile/ setting.
Usage would look something like this in the urls.py:
(r'^login/$', 'django.contrib.auth.views.login', \
{'template_name': 'account/login.html', \
'default_redirect_to': '/'}),
Worthwhile?
In the meantime, I can set up a redirect from /accounts/profile/ to /,
but this seems hackish to me.
Cheers!
Rob
--~--~-~--~~~---~--~~
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: login_required decorator and redirect_to
Karen wrote: That would certainly do the trick, and is easy enough. Thanks, Rob --~--~-~--~~~---~--~~ 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: Regarding the copy of forms -> oldforms
Would Michael Radziej's suggestion work better for those who develop against trunk but whose servers are running stable releases (ie: 0.95)? That's my case and I just ran up against this issue. For now, I'm going to revert my local workstation to using 0.95. --~--~-~--~~~---~--~~ 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: login_required decorator and redirect_to
I ran into another spot where not having my login at /accounts/login made things difficult... I'm using the password reset functionality. When the user enters their email and they get sent a password it is including a link to the password change form. When the user isn't yet logged in, password_change has a login_require decorator which redirects to /accounts/login/. I did create my own login decorator for this site for my own views that are using it. But to use my decorator for the password views would mean duplicating (or copying) all that code. Are there any tricks one can do? Maybe tell my application that password_change = django.contrib.auth.views.password_change and use my own decorator? (Just now thought of that.) It's certainly not a big deal to make my URLs better match what Django expects. But at the outset, I assumed it would be easier. --~--~-~--~~~---~--~~ 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: Regarding the copy of forms -> oldforms
Or perhaps you have a test server which is running the same codebase as prod? Yes. We have a development server running 0.95 that matches our production server. Generally there hasn't been much different from 0.95 to trunk so I've been keeping up to date with trunk on my workstation just to follow along and read the source from time to time. It's probably safer to use 0.95 and still follow along in a sandbox if I wanted. -Rob --~--~-~--~~~---~--~~ 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: login_required decorator and redirect_to
Kenneth Gonsalves wrote:
I did create my own login decorator for this site for my own views that
are using it. But to use my decorator for the password views would
mean duplicating (or copying) all that code.
use user_passes_test - it allows you to specify the url you want.
Yes, that's what I'm doing in my own login decorator. The problem is
that if I want to take advantage of django.contrib.auth.views'
change_password method, which already has a decorator, I'm stuck.
I'm not at work and can't easily test this, but I wonder if this would
work...
# urls.py
r('/account/password_change/', \
'mywebsite.profile.views.password_change', \
{'template_name': 'account/pwchange.html'}),
# mywebsite.profile.views.py
password_change = \
login_required(django.contrib.auth.views.password_change)
... where login_required is my own custom decorator that uses
"user_passes_test" and redirects to /login/ instead of /accounts/login/.
I'd have to look at the code, but I think the problem would be the
password_change method is already decorated, and this would decorate it
twice.
-Rob
(This should probably on django-users at this point, my apologies for
perpetuating it here...)
--~--~-~--~~~---~--~~
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: New newforms code
I just wanted to say that this is the reason I'm reluctant to use Django's forms (new or old) no matter how stable it is. I like that any major chunk of HTML code is visible for tinkering in my template files. Maybe a template solution would be more work (probably some repetition, I haven't really thought about how to combine both some automation and custom template files), but it would also be less surprising for me. Same here. For most projects I've worked on that required forms, I've written my own because the forms output XHTML widgets and we're using HTML 4. And for all the talk of separating the database from the logic from the view, doesn't this violate this anyway -- having XHTML in the forms code? I'd much prefer the flexibility of template based forms. +1 from me on this. It's been suggested a few times in other places as well. -Rob --~--~-~--~~~---~--~~ 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
James Bennett wrote: > I'm using HTML 4.01 (quite happily, I might add) and running into > annoyance with the fact that both Django's newforms and the old > manipulator system default to XHTML-style tags with no way to override > that. James, I'm in the same boat. I'm curious why you don't use XHTML? For me, it's some of the exact reasons that Ian Hickson states, but I was curious about others. http://www.hixie.ch/advocacy/xhtml -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Possible bug? Conflict between filter with related table and extra-tables?
I was trying to write a fairly complicated query to pull in content across tables in one query rather than having to break it up into many queries. In playing with this I think I found a bug. Note: I've simplified the call slightly by using a different part of the data model than what I'm really after, but it makes it clearer I think. This can preferably be done with select_related() in this example but the real query I'm after cannot since the FK is in the next table over. Anyway... This correctly adds "page_item" to the FROM clause by using extra(). Notice I'm not yet referencing a related table in the filter() clause. In [29]: Page.objects.extra( tables=['page_item'], where=['page_item.page_id=page_page.id']) .filter(template__id='1')._get_sql_clause() Out[29]: (['`page_page`.`id`', '`page_page`.`number`', '`page_page`.`title`', '`page_page`.`template_id`', '`page_page`.`description`'], ' FROM `page_page` , `page_item` WHERE page_item.page_id=page_page.id AND (`page_page`.`template_id` = %s)', ['1']) But adding the related table in the filter() clause breaks the extra() tables and "page_item" disappears... In [30]: Page.objects.extra( tables=['page_item'], where=['page_item.page_id=page_page.id']) .filter(template__name='Default Template') ._get_sql_clause() Out[30]: (['`page_page`.`id`', '`page_page`.`number`', '`page_page`.`title`', '`page_page`.`template_id`', '`page_page`.`description`'], ' FROM `page_page` INNER JOIN `page_template` AS `page_page__template` ON `page_page`.`template_id` = `page_page__template`.`id` , `page_item` WHERE page_item.page_id=page_page.id AND (`page_page__template`.`name` = %s)', ['Default Template']) I'm going to try a workaround in my real query by shifting my query over to the next related table so select_related() can follow the FK backwards but this requires my query to be broken into multiple queries. I thought this was worth pointing out, though. I would expect that having a related table in the filter shouldn't drop the extra tables. -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Should Django be HTML agnostic?
I posted a bug (http://code.djangoproject.com/ticket/3280) before I left work which quickly got shot down by Adrian. :) He's right in that it's a pretty general bug so I bring the conversation here. I'm curious what the Django devs will make of my reasoning... I realize some of these aren't directly related to whether Django itself prefers XHTML. Some are more along the lines of how easy it should be to work around Django if you prefer HTML4. The following are what I think are valid reasons why Django should be HTML agnostic. 1. Display code should be separate from logic. Ideally, all HTML would be in template files that one could override if need be in their own template directory, just like the admin templates. If django.forms did this, that would be great. The only consideration I can think of is what kind of load would this be to necessitate a file system call to pull in the widget template or error template? 2. The argument against #1 that I've seen is usually that you can subclass Something and write your own output. But in some ways, this violates the DRY principle. The code to output a form widget, for example, is already written, and in looking at what it would take, the only change in the render() method would be the change of the HTML itself. 3. Better "updatability": If there is a bug in Select(Widget) that was fixed but I have MySelect(Widget) which is mostly the same except for the HTML, I wouldn't get the fix unless I noticed and updated my code as well. Whereas if Select(Widget) pulled in a template and I overrode that template, the fix would come down just fine across all my projects. 4. One of the reasons I've seen touted for the template system not having access to Python methods and having it's own language is the benefit of separating the programmer from the designer and that designers shouldn't need to know Python to create templates in Django. But they would if they want to manipulate forms or form error feedback. This should be consistent. If there's agreement, I'd be happy to help in the effort to make this happen. Initially I suppose the discussion is whether this is worth it at all. I also grepped the code looking for HTML tags and besides a few places (the Django error page, for example) this is directed at django.forms (newforms). Thanks, Rob --~--~-~--~~~---~--~~ 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: Should Django be HTML agnostic?
Michael Radziej wrote: > I'm not sure what you mean exactly with "HTML agnostic". Could you > explain it, please? Just that Django shouldn't favor XHTML over HTML4. But I'm actually not too concerned if it comes with django.forms that default to XHTML, but they are easily configurable or easy to override via templates. So the title is a bit of a misnomer -- the bullet points explain what I'm after better. Cheers! --~--~-~--~~~---~--~~ 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: Should Django be HTML agnostic?
I think it's in the other thread, but what's the reason for wanting to decouple forms from templates? I can think of 2 reasons: 1) Decoupling means you can change the way templates work and not have to update the forms code. Counter argument: If you change the way templates work you'd break a lot more than forms so this will likely be a non-BC thing to do anyway. In and of itself, this isn't a great argument against keeping things decoupled. 2) Allow the form widgets to be used outside of Django. If this is the case, could it be that Django defaults to importing django.templates. If that errors out, use standard Python Template Strings as a fall back? Another question. What would it look like if form HTML output type was a config setting? DEFAULT_HTML_DOCTYPE = "HTML4" Then Django supports the common ones: XHTML and HTML4 (and others when they come along). It's extra code for every HTML type but it keeps things decoupled. This still doesn't accomplish letting designers design forms by changing templates, which I think is a good argument for widget templates. -Rob --~--~-~--~~~---~--~~ 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
Michael Radziej wrote: > BTW, what keeps me from XHTML is simply that my javascript > library of choice (yui) doesn't support it in all components. Hmmm. Can you elaborate? We're using YUI for a few things as well and I wasn't aware of this. (We can take this offline if it's preferable.) > XHTML currently has a tendency to break your web site when it grows. I'd also like to hear more about this one too. --~--~-~--~~~---~--~~ 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: Windows installer (was: Moving towards Django 1.0)
Jacob Kaplan-Moss wrote: > Good point. Eugene sent me a windows installer a while ago, but I didn't have > a chance to test it out and then I lost track of it > > Let's table this until closer to the release, but if you want to talk to him > and anyone else and start lining things up for a windows installer, we'd love > to have one. I'm pretty comfortable with the Nullsoft Installer (NSIS: nsis.sf.net). If Django decides to use that, I'd be happy to help. Should we start a separate thread to answer questions like: * Should we use default Python or something like Portable Python? * Assume SQLite? * Install any add-ons (like Markdown or Textile)? -Rob --~--~-~--~~~---~--~~ 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: Windows installer
There are really at least two distinct audiences for an installer: experienced python users who will likely have a database and python version installed along with various add ons, and new python users who may be thinking about moving from LAMP (where the P is PHP) to either Ruby on Rails or hopefully Django and Python. I think we should target the new users and create the installer to install a sort of "sandboxed" Django -- Django intended to use its internal web server for those who just want to download and play. To that end, I think including SQLite and a few other common bits would be useful just to test out Django and develop against. My 2 cents. -Rob --~--~-~--~~~---~--~~ 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: Windows installer
PS: This could also be used as an example of how to build an installer for your app to send to someone for reviews. Something we're going to need where I work in the not so distant future. --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
Adrian Holovaty wrote: > Graham and/or anybody else who wants multi-threading in the > development server, can you try this patch and see whether it solves > your problem? I updated my Django trunk with the ThreadingMixIn patch and looking at a couple projects that have media served statically (for development). I think this is proof that it is multi-threaded. Notice how the original request shows up 2nd instead of first: Django version 0.96-pre, using settings 'innovate.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C. [22/Jan/2007 10:15:29] "GET /media/css/style.css HTTP/1.1" 200 6743 [22/Jan/2007 10:15:29] "GET / HTTP/1.1" 200 8014 [22/Jan/2007 10:15:29] "GET /media/css/print.css HTTP/1.1" 200 471 [22/Jan/2007 10:15:29] "GET /media/img/orcas_logo.gif HTTP/1.1" 200 4788 Also, I looked at the Firebug Net view to see how the 4 pieces are loaded. The threaded server shows the 4 pieces with the HTML overlapping the requests for CSS and image. Whereas the default Django never has complete overlap -- requests always finish after the previous one. (I'll attach the images in the next message since I'm in the Google Groups web form right now...) -Rob --~--~-~--~~~---~--~~ 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 with CherryPy 3.0
On Jan 23, 7:55 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > Keeping in mind the comments about possible thread-safety heisenbugs, > let's make it so that the threaded behavior is *optional*, but people > can turn it on if they're concerned about Ajax-induced stalling. What > do you think? Anybody willing to update the patch and post it into our > ticket system? Credit should definitely go to Istvan Albert, but I started a patch with documentation update(s) here: http://code.djangoproject.com/ticket/3357 --~--~-~--~~~---~--~~ 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: Critical ticket: can cause data loss
Wow, I didn't even know those existed. Besides this bug, are these considered stable? Are there plans to document them? I've got a data model that we may need to implement that could use just this feature. If we start playing around with them and see how they work I can try to help provide some docs. -Rob On Jan 25, 3:32 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 1/23/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > > On 1/23/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > I've just attached a unit test to the ticket. It seems to be the same > > > issue described in #2749 and #3081. I think I understand the problem; > > > the patch on #3081 is pretty much correct. I should have this sorted > > > out by tonight. > > > Ok - I've attached a patch with a fix to #3215. The fix is pretty much > > what is attached to #3081, cleaned up for a couple of edge cases. The > > patch fixes #3081, #3215 and #2749. > > > I haven't committed the fix - it's late, I'm jetlagged, and I'm not > > completely certain I haven't missed an edge case (in particular, the > > reverse case - the patch for #3081 contains protection in the > > reverse_m2m traversal, but as far as I can make out generic relations > > don't have a reverse representation).My jetlag has worn off, so now I can > > see the obvious problem that I > missed on Tuesday. I've checked in the fix as [4428]. > > Russ Magee %-) --~--~-~--~~~---~--~~ 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: Critical ticket: can cause data loss
On Jan 25, 10:35 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote: > and the > small fraction of people using them probably all subscribe to this > mailing list If there's not 100% certainty, I'd argue that it deserves a new point release. It just takes 1 person for this to bite and post a rant to get negative publicity. And after all the hard work of trying to do things the right way, that would suck. Where I work we go from project to project quickly. The nice thing about the point releases is that they're plain as day. If I was using 0.95 for that last project, I should upgrade to 0.95.2 b/c those are important fixes and only fixes (no new features that might break things). That's easy. Having to go to 0.96 or follow leads into a conversation on the dev list. That's not as simple. -Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django ORM bug when your app has a model named "ContentType"?
I'm getting a weird bug here and this is what I've deduced... I've got a "Page" model and a "Content" model. Content has a FK to Page. I also have a "ContentType" model and Content has a FK to ContentType. This is where I tell it if the content is text or other media content. The problem comes when I use Content.objects to pull data... This works: Content.objects.filter(page__number=11020) But this doesn't: Content.objects.select_related().filter(page__number=11020) When I view the SQL, the one with selected_related includes invalid tables in the SELECT clause, namely: '`page_contenttype6`.`id`', '`page_contenttype6`.`name`', Even though it already has the real tables: '`page_contenttype`.`id`', '`page_contenttype`.`name`', When I look in the django_content_type table, the row with id=6 is: | 6 | content type | contenttypes | contenttype | This seems like too much of a coincidence. The row for the "ContentType" content type is this: | 10 | content type | page | contenttype | How can I help further debug this? --~--~-~--~~~---~--~~ 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 ORM bug when your app has a model named "ContentType"?
> Django has a builtin type called "ContentType", > http://code.djangoproject.com/browser/django/trunk/django/contrib/con... > > I'd just rename yours to something else and be done with it. As a workaround, sure. I've already worked around the issue. But I don't think Django would want this type of restriction. I've tried to track how this might get in the SQL myself but it's beyond me. I'm just offering to help assist or share my model offline if needed. -Rob --~--~-~--~~~---~--~~ 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 ORM bug when your app has a model named "ContentType"?
> Keep in mind that django.contrib.contenttypes gets installed by
> default, and is used by the comments app, the auth app, the admin app
> and the generic relations framework.
>
> It's hard to escape it :)
I quickly grepped the docs directory and it's not mentioned that you
can't have a model named "ContentType". If Django wants this to be a
reserved model name, then at the least this thread can result in
documenting that.
But it's just a model name... Django doesn't break if you have an app
with a model name of "Car", and another app with a model name of "Car".
It's pretty good at keeping the models separated by app. I took at look
at django.db.models.loading from the shell and it's keeping everything
straight and tidy as a list of:
{'app': 'model1', 'model2', ... }
I guess I thought that this would be a straight forward fix for someone
who knows the ins and outs of the ORM well -- a special case buried
somewhere.
-Rob
--~--~-~--~~~---~--~~
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: Status update on newforms-admin branch
> I agree this approach is a huge improvement over the current syntax,
> but I wonder whether it can be expanded even more. Instead of
> dictionaries, let's use objects:
Woah... inline that is specified by objects that can be subclasses?
I'll have to wrap my head around that one.
Would it be possible to nest inlines? This is one limitation we
sometimes bump up against since our data model spans more than a few
relationships sometimes, and it would be nice to have greater inline
depth.
For example, if you have:
class Kingdom(models.Model):
#
class Admin:
inlines = (
StackedInline('Phylum')
)
class Phylum(models.Model):
kingdom = models.ForeignKey(Kingdom)
class Admin:
inlines = (
StackedInline('Class')
)
class Class(models.Model): # ignore the reserved word :)
phylum = models.ForeignKey(Phylum)
class Admin:
inlines = (
StackedInline('Order')
)
etc...
Could that work and span all those relationships, following the
relationships as it goes.
-Rob
--~--~-~--~~~---~--~~
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: Developer documentation?
I'd like to see more inline documentation of the code. Some .py files have this but some don't. Just an overview of what the file does, how things are organized, maybe some concrete examples via doctests. Something for the average python programmer to get a toehold into what the code is doing. Inline in the code seems like a good place for this to me. It can be updated as the code changes. And those digging around in the code are the ones who will benefit the most from it. Cheers! -Rob --~--~-~--~~~---~--~~ 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: Fwd: passing arguments to the login_required decorator
#3185 fixes these also: #3372, #3407 (there may be others). That patch would make me happy. Thanks, Rob On Feb 7, 12:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > Forwarding this here, because the problem would go away if we could > get some attention on ticket #3185: > > http://code.djangoproject.com/ticket/3185 > > -- Forwarded message -- > From: Mike H <[EMAIL PROTECTED]> > Date: Feb 7, 2007 6:16 AM > Subject: passing arguments to the login_required decorator > To: django-users@googlegroups.com > > Hi all, > > I am using the login_required decorator form > django.contrib.auth.decorators, but I want to override the second > argument which specified which url it should redirect to if the user is > not logged in. > > I'm pretty new to python and everything I've tried so far has just > resulted in a syntax or name error. The only solution I have working is > to write my own decorator that calls the decorator in contrib.auth but > that seems messy. > > How can I pass in the user to authenitcate and the login url arguments to > the decorator directly? > > Thanks, > > Mike > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Regarding the use of sha in contrib.auth
Since SHA-1 was recently found to have some collisions, and since sha is deprecated in Python 2.5 in favor of hashlib, should an attempt to import hashlib be added to contrib.auth.models (both check_password and set_password) so when Python 2.5 becomes more mainstream, this will be picked up by default? Hashlib docs: http://docs.python.org/lib/module-hashlib.html Both md5 and sha have deprecation warnings: http://docs.python.org/lib/module-md5.html http://docs.python.org/lib/module-sha.html --~--~-~--~~~---~--~~ 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: Regarding the use of sha in contrib.auth
On Feb 8, 9:36 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > Using hashlib to generate SHA1 when it's available is something I > could get behind. Deprecating SHA1 hashes, not so much Totally agree... the news about SHA-1 made me want to look up Python's cryptographic functions as a curiosity. SHA-1 isn't going away any time soon. A new hashing method won't even be picked by NIST until 2011. It's still early, but I think adding support for hashlib is good, especially since Python appears to be deprecating anything else. As an extra option, could we also add support for sha-256 in contrib.auth if folks would prefer that? -Rob --~--~-~--~~~---~--~~ 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: Regarding the use of sha in contrib.auth
Should I file a bug to eventually use hashlib for >= Python 2.5? Should I provide a patch which attempts to import hashlib and use it if available, but otherwise falls back on md5/sha1? Some general confusion about what's going on in contrib.auth.models... There's 2 check_password methods in there. 1 in the global namespace and 1 in the User class. User.check_password is there mainly to check for an md5 password (by absence of a '$') and if it is an md5 password, it converts it to the sha1 password and passes handling to the global check_password. But set_password will only set a sha1 password. So why would the global check_password need to check if the algo is 'md5' if set_password could never use md5? Could Django remove the BC check prior to 1.0 to clean this up? I guess those applications that are in active use with real users this would be bad since the only way to migrate this to sha1 would be to know the actual password. Maybe I answered my own question. :) --~--~-~--~~~---~--~~ 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: Regarding the use of sha in contrib.auth
Malcolm Tredinnick wrote:
> Be careful to ensure backwards compatibility. Otherwise an
> inconsequential Python upgrade (to 2.5) will mean all your previously
> recorded passwords are now unusable. You need to at least be able to
> check for SHA1-style hashes and use those if necessary no matter which
> version of Python you are using.
Good point. I did a quick test and the SHA-1 hashes are equivalent...
Python 2.4.3 (#1, Nov 3 2006, 21:03:52)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import random
>>> rand = str(random.random())
>>> rand
'0.55628289848'
>>> import sha
>>> salt = sha.new(rand).hexdigest()[:5]
>>> raw_pass = 'turing'
>>> hsh = sha.new(salt+raw_pass).hexdigest()
>>> '%s$%s$%s' % ('sha1', salt, hsh)
'sha1$cb374$bd6289a5f976888b532141483391c108656edfb5'
Python 2.5 (r25:51908, Nov 3 2006, 20:49:30)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> rand = '0.55628289848'
>>> import hashlib
>>> salt = hashlib.sha1(rand).hexdigest()[:5]
>>> raw_pass = 'turing'
>>> hsh = hashlib.sha1(salt+raw_pass).hexdigest()
>>> '%s$%s$%s' % ('sha1', salt, hsh)
'sha1$cb374$bd6289a5f976888b532141483391c108656edfb5'
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Proposal: if form name is like "name[key]", convert to dict in request.POST
This is obviously borrowed from PHP but I think there are useful
reasons to copy this behavior.
The idea...
If one constructs their HTML forms, naming their form elements as
"name[key]" like so:
etc.
Django would then convert this to a dictionary of form:
f = {
'name': 'value of f[name]',
'address': 'value of f[address]',
'city': 'value of f[city]'
}
This is also useful for grouping multiple select boxes:
One
Two
Three
(I'm not sure how Django handles multiple selects currently.)
Processing within Django, to me, becomes simpler, and one can do
things like the following rather than iterating over all items in
request.POST:
if request.POST.has_key('f'):
for k,v in request.POST['f'].iteritems():
# process key/value pairs in some way
Grouping your forms into dicts like this also lets you do iterative
logic while avoiding other POST items (eg: input type=submit values or
X,Y coordinates).
I'm not sure how this would tie in with newforms since we're not using
Django's forms and validation (at least for now).
Cheers!
Rob
--~--~-~--~~~---~--~~
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: Proposal: if form name is like "name[key]", convert to dict in request.POST
On Fri Feb 09, 2007 at 02:54:44PM -0800, SmileyChris wrote: > > Hi Rob, there's similar functionality in Django already (but it's > undocumented afaik) using a custom data structure called > DotExpandedDict: > http://code.djangoproject.com/browser/django/trunk/django/utils/datastructures.py#L215 > > I just opened a ticket regarding it's undocumented nature. Interesting. I'm guessing it's not wired up to request.POST... I tried naming my form like name="name.key" and got no DotExpandedDict love. :) Thanks, Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Model.objects.get() raises AssertionError on multiple values
I'm wondering if maybe get should raise an error with a name like "MultipleValueError" rather than "AssertionError" when multiple values are found... Yesterday I was wiring up a toggle method. If the row is in the database, remove it. If it isn't in the database, add it. I don't have the exact code in front of me but it was something like this: def mytoggle(var): try: setting = Setting.objects.get(var=var) setting.delete() except DoesNotExist: setting.objects.create_setting(var=var).save() except AssertionError: setting.objects.filter(var=var).delete() The check for AssertionError is a "just in case" check that somehow the variable slipped in there twice. But I'm wary of attaching code to an assertion error. I don't have a lot of Python experience so maybe that's reasonable. Thanks, Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
newforms: Subclassing forms and sequencing?
I saw this changeset go in and am wondering if it is possible to specify a sequence order for the fields to display. Example: class Person(Form): first_name = CharField() last_name = CharField() class PersonWithMiddle(Person): middle_name = CharField() But where you want this to display like this: >>> print p.as_ul() First name: Middle name: Last name: Instead of middle name getting appended to the end. I personally don't have a specific need for this currently. Mostly curious. -Rob --~--~-~--~~~---~--~~ 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: Model.objects.get() raises AssertionError on multiple values
Cool. I was looking at how I'd do this but I wouldn't have known about the add_to_class in __new__. On Feb 16, 12:18 pm, "Gary Wilson" <[EMAIL PROTECTED]> wrote: > Ticket and patch created:http://code.djangoproject.com/ticket/3511 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
app completion in django_bash_completion - testing please
I implemented app completion and would like comments and testing for
those on *nix.
What's the easiest way to provide a patch? Open a new ticket and
attached? Or attach it to the original bash_completion ticket here:
http://code.djangoproject.com/ticket/1240 ? I'm pasting the diff
below so people can test for now.
A couple notes:
* My patch uses sed, grep, and tr instead of the previous patch which
uses Python. The Python way does seem nice since Django already knows
about its own apps. But Adrian made a comment on the ticket above
that it didn't work for him.
* Depends on settings.py being named "settings.py" and depends on the
user being in the project root directory (where settings.py is). The
previous patch had this dependency too.
* This essentially does the following (each command):
1. Filters settings.py and prints everything in INSTALLED_APPS
2. Strips any lines with django in them
3. Does pattern matching to get the app name.
4. Finally, tr merges the separate lines into a single line with
apps separated by spaces.
It's working on my Mac. If I type "./manage.py sql " and press tab
twice, I get a list of apps and starting to type one does tab
completion.
Comments appreciated.
-Rob
Index: extras/django_bash_completion
===
--- extras/django_bash_completion (revision 4557)
+++ extras/django_bash_completion (working copy)
@@ -79,10 +79,12 @@
adminindex|install|reset| \
sql|sqlall|sqlclear|sqlindexes| \
sqlinitialdata|sqlreset|sqlsequencereset)
-# App completion isn't yet implemented, but here's where
that
-# would go.
-# COMPREPLY=( $(compgen -W "auth core" -- ${cur}) )
-COMPREPLY=()
+# App completion
+apps=`sed -n '/INSTALLED_APPS = (/,/)/p' settings.py | \
+ grep -v django |
+ sed -n "s/^[ ]*'.*\.\(.*\)'.*$/\1 /pg" | \
+ tr -d '\n'`
+COMPREPLY=( $(compgen -W "${apps}" -- ${cur}) )
return 0
;;
--~--~-~--~~~---~--~~
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: app completion in django_bash_completion - testing please
I re-opened bug 1240 and added my patch there: http://code.djangoproject.com/ticket/1240 --~--~-~--~~~---~--~~ 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: app completion in django_bash_completion - testing please
This morning I'm working on a few things with this... > I'd like to change the "grep -v django" line with "grep -v > django.contrib" so that applications containing "django" as a part of > their name (ex. djangotestproject.appname) are not discarded. Good point, I'll add it in to the next patch. > Then I'd like that completion script would support names as 'appname' > instead of 'projectname.appname'. I got this work for myself using > s/^[ ]*'\(.*\.\)*\(.*\)'.*$/\2 /pg as regular expression in sed. Right, another good point. I added in support for stuff after the closing quote because in our settings.py we usually set PROJECT_NAME near the top and re-use it in our script, so our installed apps look like this: '%s.appname' % PROJECT_NAME, And this supports that. I'll update it to support just 'appname' as well. I'm also adding checks for the environment variable DJANGO_SETTINGS_MODULE so this doesn't have to be in the same directory to work. I'll post an updated patch. Thanks, Rob --~--~-~--~~~---~--~~ 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: Upcoming Django release, and the future
Could we get a design decision on whether to add default, non-django looking 404 and 500 templates? It seems pretty minor but important as there are 2 cases where switching from DEBUG=True in development to DEBUG=False for production could end up biting you... 1) With DEBUG=False and a 500 occurs and there's no 500.html, Django exposes a traceback... http://code.djangoproject.com/ticket/760 2) If using flatpages... http://code.djangoproject.com/ticket/3335 Adding a fallback 404 and 500 template would fix these. -Rob --~--~-~--~~~---~--~~ 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: Upcoming Django release, and the future
On Feb 26, 9:46 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > I've close #760 and #3335 with this comment: Design decision: Django won't include default 404 and 500 templates. OK. But does that invalidate those bugs? The default templates were a possible solution to fix both of them. Both of these bite the end user when they migrate from development to production so these seem especially ugly to me... changing DEBUG shouldn't break your site. Perhaps under DEBUG=True Django should detect the existence of 404.html or 500.html when one of these errors occurs? Or maybe ./manage.py validate should perform this check? If anything, flatpages docs should mention to the user to make sure they have a 404.html template or it will break when DEBUG=False. That's certainly something I could provide a patch for. Is there another place to add docs that all projects must contain 404.html and 500.html templates? Thanks, Rob --~--~-~--~~~---~--~~ 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 not thread-safe?
This patch being: * good for local testing that more closely resembles a real hosting environment (eg: with AJAX testing) * for the development server only * and disabled by default you'd think it would be an easy inclusion. I'd like to know more too. -Rob --~--~-~--~~~---~--~~ 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 ORM bug when your app has a model named "ContentType"?
On Feb 9, 3:12 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > So after some back and forth about whether this should or shouldn't > work, there didn't seem to be any resolution. Your gut feeling looks > right to me Rob: it should probably work as you expect (no collision), > although it won't surprise me if it doesn't (because ContentTypes are > mixed into generic relations, which is part of core still). > > I'll have a look at this, since I've delved into models.loading a lot in > the past (and intend to do so again in the near future). After seeing the select_related(depth) patch go in, that made me want to see if limiting the depth of this affected the error I was seeing in the SQL. Result: it doesn't affect it. Using select_related() still adds those strange tables that don't really exist. But! I did find the root of what's causing this bug and it may occur regardless of the name of the model... Our content system has these relationships: Content -> ContentType Content -> Attribute -> ContentType There's more than one way to follow the relationships to land at ContentType. (Aside: We originally added ContentType to Attribute so we could filter the pulldowns of our Attributes by ContentType since our content attributes only make sense for certain types of content.) If I remove the FK from Attribute -> ContentType, the extra junk in the SQL goes away. It should be easy to test this on table names other than ContentType. Hopefully this is an extra clue to track this down, and maybe this bug is already known? Cheers! Rob --~--~-~--~~~---~--~~ 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 ORM bug when your app has a model named "ContentType"?
> Could this be related to #2874 ? 2874 looks related in that it is another bug resulting from a similar type of circular table relationship. --~--~-~--~~~---~--~~ 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: IntegrityError patch
I like it... I had to do a all encompassing "except" just the other day because IntegrityError was in MySQLdb. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Possible bug: How does Django decide when to quote SQL arguments?
I was reviewing all the SQL calls in my page views by taking advantage of the context variable "sql_queries" when DEBUG=True. I found this query that isn't quoted correctly (I trimmed out some stuff to make this shorter): SELECT -- various fields listed here FROM `page_content` INNER JOIN `page_attribute` AS `page_content__attribute` ON `page_content`.`attribute_id` = `page_content__attribute`.`id` WHERE ( `page_content`.`page_id` = 78 AND `page_content__attribute`.`name` = Alt Page Title ) ORDER BY `page_content`.`sequence` ASC LIMIT 1 In the WHERE clause, page_content__attribute.name argument should be quoted but it's not. If I run this manually I get an SQL error. The Python line is this (which is wrapped in a try block in case we get an IndexError: title = next_page.content_set.filter(attribute__name='Alt Page Title')[0].text_content Actually, I'm seeing this in other queries as well, whenever I have an INNER JOIN it seems the WHERE arguments are assumed to be numeric (ie: not quoted). Thanks, Rob --~--~-~--~~~---~--~~ 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: Possible bug: How does Django decide when to quote SQL arguments?
On Mar 7, 11:15 am, David Danier <[EMAIL PROTECTED]> wrote: > AFAIK the queries are logged without quoting but executed correctly. > (You can see this, if you have a SQL-error and the DB-backends throws an > exception with the real query) So somewhere else in the ORM it fixes the quoting before it hands it over to the database? Thanks, Rob --~--~-~--~~~---~--~~ 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: Design decision on #3532 -- spaceless templatetag
> Ok - initial opinion appears to be anti configurability and anti > changing the default. Another option is to introduce a different tag > for the 0-spaces case. Opinions? Suggestions for names? Spaceless is > the obvious choice, but that name is taken :-) My thought was: "spaceless" is no spaces for those wanting to compress their HTML and don't care about readability. "normalize_spaces" could be a name for keeping spaces but normalizing them all to a single space. Or perhaps even "single_spaces" which is slightly less to type and provides hints to 1 space. -Rob --~--~-~--~~~---~--~~ 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: Design decision on #3532 -- spaceless templatetag
> Ok - initial opinion appears to be anti configurability and anti > changing the default. Another option is to introduce a different tag > for the 0-spaces case. Opinions? Suggestions for names? Spaceless is > the obvious choice, but that name is taken :-) My thought was: "spaceless" is no spaces for those wanting to compress their HTML and don't care about readability. "normalize_spaces" could be a name for keeping spaces but normalizing them all to a single space. Or perhaps even "single_spaces" which is slightly less to type and provides hints to 1 space. -Rob --~--~-~--~~~---~--~~ 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: ForeignKeys and friends interface
On Apr 6, 3:51 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > [An unproven gut feeling: keeping a small reminder, however subliminal, > that things are relational-database backed is actually a good idea. It > will stop widely read people from thinking there is a true object > backing store. Your notation disguises that somewhat. I'm not sure we > can avoid the leaky abstraction here because we are limited by using > relational backing stores. Acknowledging that in our notation is not > necessarily bad.] Awhile ago there was a thread on aggregate methods (SUM, AVERAGE, etc) and the stated goal was to come up with a way to make those work so that the programmer didn't require knowledge of SQL. Yet this seems to say that knowledge of the underlying SQL is good. And the keyword ForeignKey is certainly a database term and not a general English term, where maybe is_a or belongs_to might be. I'm not saying ForeignKey should change, but I'm suggesting that maybe restricting Django to come up with a way to query for aggregate functions that is more English-like doesn't seem to fit with the rest of the models and ORM that I can see. -Rob --~--~-~--~~~---~--~~ 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: Multiple Profiles
I'd like to hear what others think of this approach b/c it makes a lot of sense to me and does seem much easier in that: 1) The newly defined user object is in request 2) There's one place to get user info Thanks for sharing, Rob --~--~-~--~~~---~--~~ 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: #25582: Add a way to build URLs with query strings
At Mozilla we've used a jinja2 template filter called 'urlparams' for quite
some time. You can see the code in jingo here:
https://github.com/jbalogh/jingo/blob/master/jingo/helpers.py#L116
In Python:
urlparams(reverse('translate', kwargs={'slug': document.slug}),
to_locale=locale)
In Jinja2 templates (but the idea would be similar in Django):
https://code.djangoproject.com/ticket/25582
>>
>> {{{
>>
>> It is a common question on stackoverflow and other places:
>>
>> How to reverse() to url including GET parameters? Example:
>> .../myview?foo=bar
>>
>>
>> http://stackoverflow.com/questions/9585491/how-do-i-pass-get-parameters-using-django-urlresolvers-reverse
>>
>> http://stackoverflow.com/a/27641445/633961
>>
>> It would be very nice if django could implement a short-cut which provides
>> this.
>> It would be useful for python code and template, too.
>> }}}
>>
>> {{{
>> If we do add it, it likely needs a discussion on the
>> DevelopersMailingList
>> to figure
>> out what the API should look like. See also #10941
>> which asks for a template
>> tag for creating query strings in templates.
>> }}}
>>
>> What do you think?
>>
>>
>>
>> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0f8dbd9f-b42d-4d17-806b-d965c0999b85%40googlegroups.com
>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
-Rob
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAK2QP5bwU3s_1uzGMiwmu%2BP_u7SP5eF0zq3-E8k1sUj-TD2E7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: User_logged_in signal
I opened bug: http://code.djangoproject.com/ticket/15043 I actually stumbled on this just a few days ago while trying to put a session_key to user ID mapping into Redis upon login and was stumped for awhile why it didn't match the session key of my logged in user. -Rob On Sun, Jan 9, 2011 at 10:29 AM, Sayane wrote: > Take a look at > this: http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/__init__.py#L73 > Is there any reason, why this signal is sent before flushing session? It > makes request.session useless for all receivers. > > -- > 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. > -- -Rob -- 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.
Understanding HTML, XML and XHTML
I'm pretty sure this has been beaten to death, and I was going to pass
on sending this in, but this paragraph made me ask, "What would it
hurt to ask?":
{% block quote %}
Unfortunately, sometimes you are not fully in control of the content
you produce. For example, this very blog, published with WordPress
tags. If you find yourself in this same boat, encourage your tools
vendors to provide support for generating valid HTML.
{% endblock %}
That came from this article which puts up some very strong points
regarding HTML and XHTML and browser rendering (preferring HTML4), and
points out that many leading web standards experts are also
recommending HTML4:
http://webkit.org/blog/68/understanding-html-xml-and-xhtml/
(Donning flame retardant suit b/c I'm sure I'll get flamed for being a
retard here...)
Is Django really the web framework for *perfectionists* if it, by
default, prefers the imperfect XHTML in newforms and the admin (and
other places)? If not a complete switch, could we at least not make
those who are anal about outputting HTML4 not have to work[1]
harder[2] than[3] those who are ok XHTML?
-Rob
[1] http://www.djangosnippets.org/snippets/618/
[2] http://www.djangosnippets.org/snippets/716/
[3] http://code.djangoproject.com/ticket/6925
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
