Re: ticket #1891 review? distinct=True no longer works in limit_choices_to
Hi Matthew, On Tue, 2006-07-18 at 13:31 +1000, Matthew Flanagan wrote: > Hi, > > This ticket #1891 [1] has been outstanding for quite a while. I'm in > the process of rolling out a large application that would really > benefit from this being fixed. Is anyone able to look at it? > > Malcolm, did you ever get around to proving your idea in your last > comment in the ticket? I still the idea there is right: we can deduce when distinct() is needed. I haven't ever gotten around to writing a patch, though. Thanks for the prompt. That area of the code is in a temporary freeze at the moment whilst Adrian is refactoring the query stuff. So it will have to wait a little longer. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ticket #1891 review? distinct=True no longer works in limit_choices_to
Hi, This ticket #1891 [1] has been outstanding for quite a while. I'm in the process of rolling out a large application that would really benefit from this being fixed. Is anyone able to look at it? Malcolm, did you ever get around to proving your idea in your last comment in the ticket? [1] http://code.djangoproject.org/ticket/1891 thanks matthew --~--~-~--~~~---~--~~ 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: would is_loggedin be better than is_anonymous?
Hi Gary, On Mon, 2006-07-17 at 18:12 -0700, Gary Wilson wrote: > Patch for is_authenticated implementation with doc changes and no > deprecation warnings in is_anonymous. Please review. > > http://code.djangoproject.com/attachment/ticket/2332/is_authenticated.2.diff I'm going to sit down this evening and close some tickets. If nobody gets to this before then, I'll deal with it then. Cheers, Malcolm --~--~-~--~~~---~--~~ 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: USE_I18N = False side effect
Yes. All works now. Thank you Adrian. --~--~-~--~~~---~--~~ 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: would is_loggedin be better than is_anonymous?
Patch for is_authenticated implementation with doc changes and no deprecation warnings in is_anonymous. Please review. http://code.djangoproject.com/attachment/ticket/2332/is_authenticated.2.diff --~--~-~--~~~---~--~~ 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: Akismet spam filtering for Trac
> """ > 2006-07-17 17:13:08,419 Trac[__init__] WARNING: 500 Internal Error > (Akismet rejected spam) > """ > > Seems to be working. Good to hear. --~--~-~--~~~---~--~~ 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: Akismet spam filtering for Trac
Jacob Kaplan-Moss wrote: > On Jul 17, 2006, at 4:26 PM, Gary Wilson wrote: > > Has anyone seen/tried the Akismet spam filtering plugin for Trac: > > http://trac.edgewall.org/wiki/SpamFilter#Akismet > > > > Would be nice for Django's trac. > > Enabled -- let's see how it works :) >From the log file: """ 2006-07-17 17:13:08,419 Trac[__init__] WARNING: 500 Internal Error (Akismet rejected spam) """ Seems to be working. I'm not sure if there's any way to tweak it or see the rejected messages, but I'll take a few false-positives if it helps with the spammers. Jacob --~--~-~--~~~---~--~~ 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: Akismet spam filtering for Trac
On Jul 17, 2006, at 4:26 PM, Gary Wilson wrote: > Has anyone seen/tried the Akismet spam filtering plugin for Trac: > http://trac.edgewall.org/wiki/SpamFilter#Akismet > > Would be nice for Django's trac. Enabled -- let's see how it works :) Jacob --~--~-~--~~~---~--~~ 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: javascript image preloading from templates?
Oops that was supposed to go to user list, sorry. Iain Duncan wrote: > Hello fellow djangoers. I've been doing a gallery site that is too image > heavy for it's own good ( yes, I'm subcontracted by a graphic designer > ... ), and am trying to find good ways to control image loading so that > the user will wait and then see all the numerous and large images at the > same time instead of seeing them pop up one at a time. I managed to get > this to work ok on the first page using a javascript loaded in the head > that preloads hard full paths to the images and delays the rest of the > page load until images will be done. However, I can't get the same > things to work properly in the rest of the site when I use dhango > templates to preload. Is there perhaps some weirdness about combing > django templates with javascript preloads that I don't know about? Any > tips on how I should go about this? > > The old home page is at: > http://bmg.webfactional.com > The load controlled version that is working is at: > http://bmg.webfactional.com/test > The page that doesn't work the way I want is if you go from the above to > the artists section. > > If any one has tips for this javascript newby, many thanks! > Iain > > > > --~--~-~--~~~---~--~~ 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: Default arguments for RegexURLResolver
On 7/17/06, Martin <[EMAIL PROTECTED]> wrote:
> > How does your patch work? In your example, would it just add
> > {'weblog_slug': 'guestbook'} to every infodict in the included
> > URLconf?
> it is a fairly simple change (so maybe I over looked something)
Hi Martin,
That answers my question! Sure, go ahead and post the patch to
Django's ticket system -- it'll be a nice improvement. Thanks for the
patch, and for bringing this up!
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: Default arguments for RegexURLResolver
Martin wrote: > Once a sub_match as beed found (in `RegexURLResolver.resolve`) the dict > passed to the contructor of `RegexURLResolver` will be merged with the > dict of prefix-match, the sub_match (so instead of merging 2 dict, now > 3 dict are merged and the default_args dict has to lowest `priority`) +1 from me. I needed this functionality a while back to allow apps to appear at multiple (hardcoded) URLs, passing in an ID to customize the content. My workaround was a bodge! -- Steve --~--~-~--~~~---~--~~ 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: Default arguments for RegexURLResolver
Hi Adrian,
> How does your patch work? In your example, would it just add
> {'weblog_slug': 'guestbook'} to every infodict in the included
> URLconf?
it is a fairly simple change (so maybe I over looked something)
I only had to change to files:
conf/urls/defaults.py
just pass the third parameter to the constructor of `RegexURLResolver`.
core/urlresolvers.py:
The passed dict will be saved in the `RegexURLResolver` instanced.
Once a sub_match as beed found (in `RegexURLResolver.resolve`) the dict
passed to the contructor of `RegexURLResolver` will be merged with the
dict of prefix-match, the sub_match (so instead of merging 2 dict, now
3 dict are merged and the default_args dict has to lowest `priority`)
I can post the patch here, if this would help to understand the
changes.
Martin
--~--~-~--~~~---~--~~
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: Table options in CREATE TABLE..
Geert Vanderkelen wrote: > Hi! > > I'm currently looking into a possibility to define per Model which MySQL > Storage Engine it should use for creating the table. This would need a new > option called 'db_table_option' for the Model. .. Ok. Sorry for the noise, idea binned by all mighty FAQ. :) Thanks, Geert -- Geert Vanderkelen http://some-abstract-type.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Table options in CREATE TABLE..
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > No.. This is about table options. All of them! Not only storage engine > choice. All of the table options anyone can imagine. And "all of the table options anyone can imagine" are supported by that FAQ answer, as long as they can be applied to a table after it has been created. :) I don't think we should add this hook to Django models, for the reasons James has outlined, and because the raw SQL hook mentioned in that FAQ should be more than adequate. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Table options in CREATE TABLE..
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > No.. This is about table options. All of them! Not only storage engine > choice. All of the table options anyone can imagine. I still feel like it's way too much of a special case to try to do this; the proposed option of an "anything goes" extra string argument for throwing in a kitchen sink worth of table options feels ugly and hackish, and any other solution would end up being nightmarishly complex. Again, I think it's out of scope to expect an ORM to support every possible table option in every database. > I'm trying to make life easier to all of those people needing to do an ALTER > TABLE like that. This tiny change might just do that. > Is it to simple solution? :) The FAQ item Adrian linked provides a pretty clean way to handle this, though; if you're going to distribute an application which relies heavily on DB-specific options which are unsupported in the ORM, you can drop the SQL to add them into a file, and anyone who installs the application will get them -- Django automatiically executes that "initial data" file when syncdb is installing things. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Table options in CREATE TABLE..
Hi James, James Bennett wrote: > On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: .. > 1) The features common to all the RDBMS products it can be used with. > 2) A way to manually tweak its SQL output to take advantage of > features which only apply to one database. Well, my 'manually' tweak is to inherit from models.Model, make my own ModelMyISAM with the db_table_option = 'ENGINE=MYISAM' set to the META and use it in my projects. (I know there are more issues to this..) My patch would make it easier to allow this. This goes for most other DBMS which have table options like this. This storage engine option is just an example, but most important for MySQL. .. > Do you have a proposal for dealing with the complex snarl of options > we'd end up with if we went down this road? None. It's a simple string to be added to the the META data as db_table_options, which will just put in the CREATE TABLE statement. Cheers, Geert -- Geert Vanderkelen http://some-abstract-type.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Table options in CREATE TABLE..
Hi Adrian, Adrian Holovaty wrote: > On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: >> I'm currently looking into a possibility to define per Model which MySQL >> Storage Engine it should use for creating the table. This would need a new >> option called 'db_table_option' for the Model. >> >> Not only for MySQL would this be handy, for other backends as well. I think >> for PostgreSQL the inheritance feature would need this too. > > Does this answer your question? > > http://www.djangoproject.com/documentation/faq/#how-do-i-add-database-specific-options-to-my-create-table-statements-such-as-specifying-myisam-as-the-table-type No.. This is about table options. All of them! Not only storage engine choice. All of the table options anyone can imagine. I'm trying to make life easier to all of those people needing to do an ALTER TABLE like that. This tiny change might just do that. Is it to simple solution? :) Cheers, Geert -- Geert Vanderkelen http://some-abstract-type.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Default arguments for RegexURLResolver
On 7/16/06, Martin <[EMAIL PROTECTED]> wrote:
> I just recently found out that if you use the 'include' feature to
> refer to a external URl config file the default parameter dict is
> silently ingored, e.g.:
>
> urlpatterns = patterns \
> ( ""
> , ( r"^lce/guestbook", include ("lce_at.blog.urls"), dict
> (weblog_slug = "guestbook"))
> ### the admin pages
> , (r"^lce/admin/", include ("django.contrib.admin.urls"))
> )
> In this case, the `dict (weblog_slug = "guestbook")` part will be
> ignored silently.
>
> And now I was wondering if this is a bug or feature?
>
> I have changed the code in my local sandbox to take the default_args
> parameter into account when the view is called.
>
> So, if this is considered a bug I can open a ticket and attach patch.
Hi Martin,
How does your patch work? In your example, would it just add
{'weblog_slug': 'guestbook'} to every infodict in the included
URLconf?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: "allow tags" attribute. stays/vanishes? :)
On 7/17/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: > i can do it by setting the allow_tags attribute to true > for the given "something" :) > > but this feature is not documented, so before i use it in an > application, i'd like to ask: > > could this be documented, or is this something that will be removed later? Hi gabor, That feature won't be removed later -- you can count on using it. And I've documented it in changeset [3358]. Thanks for the reminder! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Table options in CREATE TABLE..
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > This storage engine choice was only an example. There are lots of other > options which can be set per table. > As Honza replied, this is not MySQL specific and PostgreSQL as well as other > DBMS accept options like these. But pretty much all of those options are, again, specific to the particular database they go with. An ORM layer cannot and should not attempt to emulate every possible configuration of every possible RDBMS it can be used with; that way lies madness, What it should support is: 1) The features common to all the RDBMS products it can be used with. 2) A way to manually tweak its SQL output to take advantage of features which only apply to one database. > Wrong. You make a application mostly because you would like to distribute > them. You make it easy for people to install it and use it. Why else we make > frameworks? To tell users to use awk and sed? :) I dunno. Most of the apps I write are for me or my employer to use ;) Do you have a proposal for dealing with the complex snarl of options we'd end up with if we went down this road? -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Table options in CREATE TABLE..
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > I'm currently looking into a possibility to define per Model which MySQL > Storage Engine it should use for creating the table. This would need a new > option called 'db_table_option' for the Model. > > Not only for MySQL would this be handy, for other backends as well. I think > for PostgreSQL the inheritance feature would need this too. Does this answer your question? http://www.djangoproject.com/documentation/faq/#how-do-i-add-database-specific-options-to-my-create-table-statements-such-as-specifying-myisam-as-the-table-type Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Auto-escaping patch
Malcolm Tredinnick wrote: > When a variable is evaluated in a context in a template, it is > considered to be either "safe" or not (Simon used the term "escaped", > but that seemed less universally true than "safe"). As long as we're discussing terminology, might as well enumerate the situations where we'd want the terms to be applicable: Sources: 1. Ordinary string, not intended to have HTML in it, but may have or http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Table options in CREATE TABLE..
Hi James, James Bennett wrote: > On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: >> Not only for MySQL would this be handy, for other backends as well. I think >> for PostgreSQL the inheritance feature would need this too. > > How so? Postgres doesn't have multiple storage engines like MySQL > does; a Postgres table is a Postgres table. SQLite doesn't have them > either. Which is probably a very strong argument against it being a > general model option. This storage engine choice was only an example. There are lots of other options which can be set per table. As Honza replied, this is not MySQL specific and PostgreSQL as well as other DBMS accept options like these. >> What you guys and girls think? > > I think that if you need a specific storage engine for MySQL, you > should have Django output the table creation statements into a file, > edit them to add the storage engine info, then execute them ;) Wrong. You make a application mostly because you would like to distribute them. You make it easy for people to install it and use it. Why else we make frameworks? To tell users to use awk and sed? :) It's a minimal addition which will solve lots of requests. Cheers, Geert -- Geert Vanderkelen, Support Engineer MySQL GmbH, Germany, www.mysql.com Hauptsitz: MySQL GmbH, Radlkoferstr. 2, D-81373 München Geschäftsführer: Hans von Bell, Kaj Arnö - HRB München 162140 --~--~-~--~~~---~--~~ 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: Table options in CREATE TABLE..
Hi Malcolm, Malcolm Tredinnick wrote: > On Mon, 2006-07-17 at 12:15 +0200, Geert Vanderkelen wrote: >> A follow-up on my previous post, with a patch attached to make the >> db_table_options work, which was easy to put in. >> >> Any comments on this patch, or something I looked over? Otherwise I make a >> feature request with it, unless I missed it while searching for an existing >> one.. > > I'm not too familiar with how the different engines interact with MySQL, > but does using a different engine imply using a different db connection? > If so, is this something that would work reasonably seamlessly on top of > J Pellerin's multi-database Summer of Code work (different engines => > different connections => essentially different database for that model, > so it falls out of his configuration changes)? MySQL storage engines can interact with each other of course. You can join a MyISAM, InnoDB, Cluster, MERGE, MEMORY, etc, with each other in one query. No need for different connections at all. This is not only for MySQL, it's for most other backends as well. -- Geert Vanderkelen http://some-abstract-type.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Table options in CREATE TABLE..
On 7/17/06, James Bennett <[EMAIL PROTECTED]> wrote: > > On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > > Not only for MySQL would this be handy, for other backends as well. I think > > for PostgreSQL the inheritance feature would need this too. > > How so? Postgres doesn't have multiple storage engines like MySQL > does; a Postgres table is a Postgres table. SQLite doesn't have them > either. Which is probably a very strong argument against it being a > general model option. But other things can be specified there, not just the engine. In postgres, you can use this place to add information about tablespace you wish to use, the same for Oracle. This can be very important onformation for some databases and it would be useful to have a coherent way of specifying those. > > > What you guys and girls think? > > I think that if you need a specific storage engine for MySQL, you > should have Django output the table creation statements into a file, > edit them to add the storage engine info, then execute them ;) > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin > > > > -- Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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: Auto-escaping patch (terminology)
Malcolm Tredinnick wrote: > If you want to mark every "still needs cooking" string then you have to > mark *every* string that comes into the system (a la Perl's tainted > strings). Nonono ... I just was talking about terminology. We need a term for "safe" and "unsafe" strings. I take it as granted that you'll only actually mark "safe" ones. >> I'd have lots of other ideas, but feel this is getting too far. >> How about brainstorming this on irc? Perhaps suggest a time that >> suits you. > > I'll try to hang around on #django tomorrow if I don't get too busy. > But, seriously, just come up with some good names and make people pick > one. Stop letting people push back on your ideas and become The > Enforcer. Well then ... some new ideas I like: - trusted / untrusted - processed / unprocessed - resolved / unresolved (with a musical connotation processing from dissonance to consonance) - developed / undeveloped - fixed / unfixed (like in photo processing) - treated / untreated - finalized / original - trusted / tainted (why not?) - geared / bare - furnished / ? - malcomized / unmalcomized (ok, just joking ;-) And we already have: - safe / unsafe - escaped / raw or unescaped I currently have a taste for the first two, the rest is more an invitation for others ... Now come on, native speakers, you should be able to bring in more ideas! Michael --~--~-~--~~~---~--~~ 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: Table options in CREATE TABLE..
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote: > Not only for MySQL would this be handy, for other backends as well. I think > for PostgreSQL the inheritance feature would need this too. How so? Postgres doesn't have multiple storage engines like MySQL does; a Postgres table is a Postgres table. SQLite doesn't have them either. Which is probably a very strong argument against it being a general model option. > What you guys and girls think? I think that if you need a specific storage engine for MySQL, you should have Django output the table creation statements into a file, edit them to add the storage engine info, then execute them ;) -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Table options in CREATE TABLE..
On Mon, 2006-07-17 at 12:15 +0200, Geert Vanderkelen wrote: > A follow-up on my previous post, with a patch attached to make the > db_table_options work, which was easy to put in. > > Any comments on this patch, or something I looked over? Otherwise I make a > feature request with it, unless I missed it while searching for an existing > one.. I'm not too familiar with how the different engines interact with MySQL, but does using a different engine imply using a different db connection? If so, is this something that would work reasonably seamlessly on top of J Pellerin's multi-database Summer of Code work (different engines => different connections => essentially different database for that model, so it falls out of his configuration changes)? Malcolm --~--~-~--~~~---~--~~ 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: Auto-escaping patch
On Mon, 2006-07-17 at 12:00 +0200, Michael Radziej wrote:
> Malcolm Tredinnick wrote:
> > On Sun, 2006-07-16 at 21:30 +0200, Michael Radziej wrote:
> >> I'm more for 'escaped' and 'raw', but not really violently. This is a
> >> minor issue, and I wouldn't like to get the work delayed by it.
> >> Also ... I volunteer to rewrite the docs if these terms change. But
> >> only once ;-)
> >
> > "Escaped" strikes me as bogus because it's not really the case: we are
> > just saying this output can be dumped in without further escaping.
>
> I see your point, you're right. But 'safe' still isn't necessary
> safe, I can perfectly mark unsafe strings as safe ;-)
Yeah. Btw, I can completely understand the flip side of this argument;
I'm partly just doing the Devil's Advocate thing so that things end up
on a solid foundation. You guys just need to invent a good name. I'll
write the code, you do the hard bit and come up with the
nomenclature. :-)
>
> > I thought about "raw" on Saturday and wondered if it would lead to
> > confusion: is a raw string "untreated" or "should not be treated
> > further" (we intend the latter).
>
> Interesting ... I was sure for everybody it meant the first one,
> along the line 'still needs cooking'. Well ... seems not to work.
If you want to mark every "still needs cooking" string then you have to
mark *every* string that comes into the system (a la Perl's tainted
strings). The current method is to treat all strings as "untrusted" (or
requiring escaping) by default. Then we mark them when we have worked on
them. So the word you're looking for need to apply to "marked" strings,
not their former versions. (It's just too error-prone to try and catch
all strings on input and treat the ones we miss as safe.)
>
> I'd have lots of other ideas, but feel this is getting too far.
> How about brainstorming this on irc? Perhaps suggest a time that
> suits you.
I'll try to hang around on #django tomorrow if I don't get too busy.
But, seriously, just come up with some good names and make people pick
one. Stop letting people push back on your ideas and become The
Enforcer.
>
> >> I think so. Is there a case for escaping two times? I don't see any,
> >> and one could still easily craft a custom filter that does escape two
> >> times.
> >
> > Damn. Your phrasing tipped me off to a case we need this more: RSS feeds
> > and Atom content elements with type="html". :-(
>
> Hmm, really ... I've not been into RSS or Atoms, so I wasn't
> aware. I feel a little stupid about this, now. I assume that
> inside the element you have to escape html?
Only for type text="html" in Atom (which is Django's default production
method). There are a whole bunch of rules in the spec to accommodate
everybody from those who just can't get enough double-escaped markup in
their lives to those who want to use well-formed XML fragments to those
who want to shove raw bytes (base-64 encoded) in there. For RSS, things
are double-escaped everywhere as a matter of tradition.
> > We might need a "mark as unsafe" filter for these cases (so that {{ var|
> > escape|unsafe|escape }}) works (or just make "escape" not mark the
> > string as safe, but I suspect that will have unintended annoying
> > side-effects).
>
> Alternatively, you could add a filter that escapes 'safe' strings
> once and unsafe strings twice. Call it 'double_escape'. But this
> is a minor issue. I'm presently not sure what is better.
Again, I don't really care what the answer is here. I've thrown out some
ideas. People should propose better/different ones. This is very much a
non-religious issue for me beyond not wanting to sound stupid if/when I
stand up at a conference to give a tutorial on Django. So try to avoid
forming a consensus around calling the filter "elephant" or something,
ok? :-)
Regards,
Malcolm
--~--~-~--~~~---~--~~
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: Auto-escaping patch
On Mon, 2006-07-17 at 03:30 -0700, SmileyChris wrote: > Great job on the patch, Malcom! > I posted this in the ticket, then felt guilty because you told me not > to. So I'll post here for discusion. > > A couple of points: > If a markup filter fails due to an import error, I don't think it > should be marked as safe. Why not? The returned result is the empty string in that case and there's certainly no danger of that being presented in the raw. "Safe" implies nothing beyond "does not require further HTML escaping" (and that is the quite reasonable argument for finding another name for it). If a filter is returning a safe (or whatever we end up calling it) string, it should *always* return a safe string. Otherwise the end users will be uncertain about whether the returned result is safe or not and will always have to wrap it in an "escape" filter, which they will forget to do. > >From a skim read of the patch, I'm missing the purpose of having an > .is_safe property on filters - can't you just check the outputted > string to see if it's SafeData? No. Take a SafeString instance, split it do something to it, run join on the result. What you have is now a string (not a SafeString). So rather than overloading every single string method on SafeString and every single Unicode method on SafeUnicode -- which will add quite a bit of function call overhead -- and rather than requiring filter writers to always have to do "if SafeData" tests around string operations (which they'll screw up), we mark the filter appropriately. If a filter is marked "is_safe" and a safe string is passed in, then no matter how much it gets put through the meat grinder internally, we can happily convert it back to a SafeString at the end. Ditto for SafeUnicode. This makes the code much shorter and adds a large measure of certainty to the process. For filters that are not universally safe (e.g. the pluralize case I mentioned), it is still possible in some cases to internally check internally if the munging would keep a safe string "safe" and then explicitly call mark_safe() on it. That is what I intend to do to pluralize(). Thanks for the feedback anyway. Regards, Malcolm --~--~-~--~~~---~--~~ 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: Auto-escaping patch
Great job on the patch, Malcom! I posted this in the ticket, then felt guilty because you told me not to. So I'll post here for discusion. A couple of points: If a markup filter fails due to an import error, I don't think it should be marked as safe. >From a skim read of the patch, I'm missing the purpose of having an .is_safe property on filters - can't you just check the outputted string to see if it's SafeData? --~--~-~--~~~---~--~~ 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: Table options in CREATE TABLE..
A follow-up on my previous post, with a patch attached to make the
db_table_options work, which was easy to put in.
Any comments on this patch, or something I looked over? Otherwise I make a
feature request with it, unless I missed it while searching for an existing
one..
-Geert
Geert Vanderkelen wrote:
> Hi!
>
> I'm currently looking into a possibility to define per Model which MySQL
> Storage Engine it should use for creating the table. This would need a new
> option called 'db_table_option' for the Model.
>
> Not only for MySQL would this be handy, for other backends as well. I think
> for PostgreSQL the inheritance feature would need this too.
>
> There has been discussion that you can set the default engine server wide,
> and you can set it per session as well. But that's in lots of cases not what
> people want and need.
>
> For example, following should be possible:
>
> CREATE TABLE t1 ( id int ) %db_table_options%;
--
Geert Vanderkelen
http://some-abstract-type.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Index: db/models/options.py
===
--- db/models/options.py(revision 3355)
+++ db/models/options.py(working copy)
@@ -13,7 +13,8 @@
DEFAULT_NAMES = ('verbose_name', 'db_table', 'ordering',
'unique_together', 'permissions', 'get_latest_by',
- 'order_with_respect_to', 'app_label')
+ 'order_with_respect_to', 'app_label',
+ 'db_table_options')
class Options(object):
def __init__(self, meta):
@@ -21,6 +22,7 @@
self.module_name, self.verbose_name = None, None
self.verbose_name_plural = None
self.db_table = ''
+self.db_table_options = ''
self.ordering = []
self.unique_together = []
self.permissions = []
Index: core/management.py
===
--- core/management.py (revision 3355)
+++ core/management.py (working copy)
@@ -184,7 +184,7 @@
full_statement = [style.SQL_KEYWORD('CREATE TABLE') + ' ' +
style.SQL_TABLE(backend.quote_name(opts.db_table)) + ' (']
for i, line in enumerate(table_output): # Combine and add commas.
full_statement.append('%s%s' % (line, i < len(table_output)-1 and
',' or ''))
-full_statement.append(');')
+full_statement.append(') %s ;' % (opts.db_table_options))
final_output.append('\n'.join(full_statement))
return final_output, pending_references
Re: Auto-escaping patch
Malcolm Tredinnick wrote:
> On Sun, 2006-07-16 at 21:30 +0200, Michael Radziej wrote:
>> I'm more for 'escaped' and 'raw', but not really violently. This is a
>> minor issue, and I wouldn't like to get the work delayed by it.
>> Also ... I volunteer to rewrite the docs if these terms change. But
>> only once ;-)
>
> "Escaped" strikes me as bogus because it's not really the case: we are
> just saying this output can be dumped in without further escaping.
I see your point, you're right. But 'safe' still isn't necessary
safe, I can perfectly mark unsafe strings as safe ;-)
> I thought about "raw" on Saturday and wondered if it would lead to
> confusion: is a raw string "untreated" or "should not be treated
> further" (we intend the latter).
Interesting ... I was sure for everybody it meant the first one,
along the line 'still needs cooking'. Well ... seems not to work.
I'd have lots of other ideas, but feel this is getting too far.
How about brainstorming this on irc? Perhaps suggest a time that
suits you.
>> I think so. Is there a case for escaping two times? I don't see any,
>> and one could still easily craft a custom filter that does escape two
>> times.
>
> Damn. Your phrasing tipped me off to a case we need this more: RSS feeds
> and Atom content elements with type="html". :-(
Hmm, really ... I've not been into RSS or Atoms, so I wasn't
aware. I feel a little stupid about this, now. I assume that
inside the element you have to escape html?
> We might need a "mark as unsafe" filter for these cases (so that {{ var|
> escape|unsafe|escape }}) works (or just make "escape" not mark the
> string as safe, but I suspect that will have unintended annoying
> side-effects).
Alternatively, you could add a filter that escapes 'safe' strings
once and unsafe strings twice. Call it 'double_escape'. But this
is a minor issue. I'm presently not sure what is better.
Michael
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Table options in CREATE TABLE..
Hi!
I'm currently looking into a possibility to define per Model which MySQL
Storage Engine it should use for creating the table. This would need a new
option called 'db_table_option' for the Model.
Not only for MySQL would this be handy, for other backends as well. I think
for PostgreSQL the inheritance feature would need this too.
There has been discussion that you can set the default engine server wide,
and you can set it per session as well. But that's in lots of cases not what
people want and need.
For example, following should be possible:
CREATE TABLE t1 ( id int ) %db_table_options%;
For this to work, we need a change to 'management.py' in the
_get_sql_model_create(app):
try:
full_statement.append(') %s ;' % opts.db_table_options)
except:
full_statement.append(');')
But I guess there are more things to change to make this work correctly..
I'm still trying to figure that out :)
What you guys and girls think?
Cheers,
Geert
--
Geert Vanderkelen
http://some-abstract-type.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Some extentions for MySQL backend using contrib/
Hi! I was a bit playing around and missed MySQL ENUM and SET column types. Instead of adding them to the MySQL backend, I just created a new app in the contrib/ directory called 'mysqlext'. http://some-abstract-type.com/code/?cmd=manifest;manifest=76d4a786cf3bd215546af6f1bcf2d12309515d43;path=/django/contrib/ This was a workable hack ;) It wasn't really difficult to extend the field types, but do you guys see it going into the main stream contrib/ of Django one day? I'll see if I can add some more stuff there later on. I would like to have ENGINE choice per Model. This mysqlext would contain stuff which really shouldn't go in the MySQL backend of Django itself as it ain't fully compatible with others (I think that's the idea of these I guess..). Cheers, Geert -- Geert Vanderkelen http://some-abstract-type.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: new field idea
Hi django-developers,
a generic api for registration of new fields would be a good idea.
As IOC, FIFA and ISO-3166 codes are not the same this won't help me:
http://en.wikipedia.org/wiki/Comparison_of_IOC%2C_FIFA%2C_and_ISO_3166_country_codes
But IOC, FIFA and ISO-3166 should have the same api.
The only difference is the content validated against.
USStateField: length 2, isValidUSState-validator
OlympicNationField: length 3, isValidOlympicNation-validator
ISO3166Field: length 3, isValidISO3166-validator
FIFANationField: length 3, isValidFIFANation-validator
The length differs by 1.
Each validator as one difference compared to the others, the valid content, but
thats all.
There should be a parent class for this fields to realize:
variable in length and variable in valid content.
Regards,
Dirk
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
--
"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
>from django.db.models.fields import Field
import forms
class OlympicNationField(Field):
def get_manipulator_field_objs(self):
return [forms.OlympicNationField]
>from django.forms import TextField
import validators
class OlympicNationField(TextField):
"A convenience FormField for validating Olympic Nations (e.g. 'GER')"
def __init__(self, field_name, is_required=False, validator_list=None):
if validator_list is None: validator_list = []
validator_list = [self.isValidOlympicNation] + validator_list
TextField.__init__(self, field_name, length=3, maxlength=3,
is_required=is_required, validator_list=validator_list)
def isValidOlympicNation(self, field_data, all_data):
try:
validators.isValidOlympicNation(field_data, all_data)
except validators.ValidationError, e:
raise validators.CriticalValidationError, e.messages
def html2python(data):
if data:
return data.upper() # Should always be stored in upper case
else:
return None
html2python = staticmethod(html2python)
>from django.core.validators import ValidationError, CriticalValidationError
>from django.utils.translation import gettext
def isValidOlympicNation(field_data, all_data):
"""Checks that the given string is a valid three-letter Olympic Nation abbreviation"""
nations = [ 'AFG','AHO','ALB','ALG','AND','ANG','ANT','ARG','ARM','ARU','ASA','AUS','AUT','AZE','BAH','BAN','BAR','BEL','BEN','BER','BHU','BIH','BIZ','BLR','BOH','BOL','BOT','BRA','BRU','BUL','BUR','BWI','CAF','CAM','CAN','CAY','CEY','CGO','CHA','CHI','CHN','CIV','CMR','COK','COL','COM','CRC','CRO','CUB','CVP','CYP','CZE','DAH','DEN','DJI','DMA','DOM','ECU','EGY','ESA','ESP','EST','ETH','FIJ','FIN','FRA','FRG','GAB','GAM','GBR','GBS','GDR','GEO','GEQ','GER','GHA','GRE','GRN','GUA','GUM','GUY','HAI','HBR','HKG','HON','HUN','IAS','INA','IRI','IRL','IRQ','ISL','ISR','ITA','JAM','JOR','JPN','KEN','KGZ','KOR','KSA','KUW','LAO','LAT','LBA','LBR','LCA','LES','LIB','LIE','LTU','LUX','MAD','MAR','MAS','MAW','MDA','MDV','MEX','MGL','MKD','MLI','MLT','MON','MOZ','MRI','MTN','MYA','NAM','NCA','NED','NEP','NGR','NIG','NOR','NRU','NZL','OMA','PAK','PAN','PAR','PER','PHI','PLE','PNG','POL','POR','PUR','QAT','ROC','ROM','RSA','RUS','RWA','SAM','SEN','SEY','SIN','SLE','SLO','SMR','SOL','SOM','SRI','STP','SUD','SUI','SUR','SVK','SWE','SWZ','SYR','TAN','TCH','TGA','THA','TJK','TKM','TOG','TPE','TRI','TUN','TUR','UAE','UGA','UKR','URS','URU','USA','UZB','VAN','VEN','VIE','VIN','YEM','YUG','ZAI','ZAM','ZIM', ]
if field_data.upper() not in nations:
raise ValidationError, gettext("Enter a valid Olympic Nation abbreviation.")
javascript image preloading from templates?
Hello fellow djangoers. I've been doing a gallery site that is too image heavy for it's own good ( yes, I'm subcontracted by a graphic designer ... ), and am trying to find good ways to control image loading so that the user will wait and then see all the numerous and large images at the same time instead of seeing them pop up one at a time. I managed to get this to work ok on the first page using a javascript loaded in the head that preloads hard full paths to the images and delays the rest of the page load until images will be done. However, I can't get the same things to work properly in the rest of the site when I use dhango templates to preload. Is there perhaps some weirdness about combing django templates with javascript preloads that I don't know about? Any tips on how I should go about this? The old home page is at: http://bmg.webfactional.com The load controlled version that is working is at: http://bmg.webfactional.com/test The page that doesn't work the way I want is if you go from the above to the artists section. If any one has tips for this javascript newby, many thanks! Iain --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
"allow tags" attribute. stays/vanishes? :)
hi, i've found (by browsing the source-code), that if i want to put raw html code into a column in django.contrib.admin's list views, i can do it by setting the allow_tags attribute to true for the given "something" :) but this feature is not documented, so before i use it in an application, i'd like to ask: could this be documented, or is this something that will be removed later? thanks, gabor --~--~-~--~~~---~--~~ 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: Test framework for end-user applications
On 7/17/06, Jyrki Pulliainen <[EMAIL PROTECTED]> wrote: Anyway, Twill's been an ideal tool for web testing, because you cangive follow links, fill forms etc.Much like the unittest vs py.test vs nose discussion earlier, I think we should be avoiding discussions about what to bless as the 'official Django testing framework'. Twill might be appropriate or familiar to some; however, others might prefer Selenium, or another framework. Testing, as already demonstrated by this thread, is a bit of a religious discussion. In addition, the kind of testing that Twill (and Selenium, for that matter) perform is limited to validating against generated HTML; while this is a valid and useful class of test, it does not allow for validation of views independent of the rendering framework - essentially every error found in a Twill test could have two sources - the template or the view. To make matters worse, it is possible that an error in the view could be hidden by a complementary error in the template (or vice versa). However, that said, IMHO the goal of this testing effort should be to provide a set of tools that enables any developer to use whatever style of testing they think will provide helpful validation of a system. If there is some facility or feature that can be added as to Django that makes Twill testing much easier, let us know; similarly for any other framework. 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 -~--~~~~--~~--~--~---
Re: Re: urlify.js blocks out non-English chars - 2nd try?
2006/7/17, gabor <[EMAIL PROTECTED]>:
>
> Jeroen Ruigrok van der Werven wrote:
> > On 7/12/06, Julian 'Julik' Tarkhanov <[EMAIL PROTECTED]> wrote:
> >> This is handled by Unicode standard and is called transliteration.
> >
> >
> > Also, for Japanese, are you going to follow kunrei-shiki or rather the
> > more widely used hepburn transliteration? Or perhaps even nippon-shiki
> > if you feel like sticking to strictness.
>
> i think we do not need to discuss japanese at all. after all, there's no
> transliteration for kanji. so it's imho pointless to argue about
> kana-transliteration, when you cannot transliterate kanji.
We Japanese know that we can't transarate Japanese to ASCII.
So I want to do it as follows at least.
A letter does not disappear and is restored.
#FileField and ImageField have same letters disappear problem.
def slug_ja(word) :
try :
unicode(word, 'ASCII')
import re
slug = re.sub('[^\w\s-]', '', word).strip().lower()
slug = re.sub('[-\s]+', '-', slug)
return slug
except UnicodeDecodeError :
from encodings import idna
painful_slug = word.strip().lower().decode('utf-8').encode('IDNA')
return painful_slug
--~--~-~--~~~---~--~~
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: Test framework for end-user applications
On 7/13/06, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:I know Malcolm said he was going to step away from this discussion, so this is mostly for the benefit of everyone else.
Initially, I think it will be hard to have the views entirely divorcedfrom the model framework. To do that (separate them for testing
purposes) would require making it very easy to creat mock objects. While I appreciate what you're trying to say here - test one thing at a time, etc - I can't help but feel that this is overkill. We implicitly trust the Django models and query tools, so end user model tests don't require tests of basic query functionality, but then we put in a complex framework to mock the Django models so that we don't have to use the actual models during testing.
A fixture/db seeding capability provides the same testing capability with very low development effort on our part. While this testing regime is _theoreticallly_ weaker because it relies upon the validity of the models, in practice I don't see that being a very large source of potential error - certainly no larger than the confidence in the mocking framework itself, which will only ever exercised during the test process.
For template testing, I was thinking about passing in an object thatsupported the necessary attribute accesses (the beauty of everything
being accessed as "foo.bar.baz" is that faking it is reasonablystraightforward). The test takes the template source filename (or sourcestring), the canned input data and we can run assertions against the
result.Agreed, but the question that I have is 'what assertions?' 1) We could test that template + sample context -> template output == known template output2) We could do 1, but assert that template output contains known substring(s)
3) We could parse 1 into a DOM tree and validate the contents of various template tags.The problem is:(1) is extremely fragile; (2) is less fragile, but not especially helpful IMHO, (3) can only be applied to DOM-like documents.
(2) can be made more helpful with lots of string comparison methods ('n instances of string', 'string 1 occurs before string 2'). However, I'm not sure that it actually serves to validate anything useful. The Django policy of preventing complex logic from being placed in the template means that if you are able to validate at the view level that the correct context has been created and the correct template has been used, the only real test that applies to the template is 'does this page render correctly'. Testing substrings of the generated output doesn't achieve this validation - correct rendering can only be answered by 1) direct comparison with a known correct example, or 2) visual inspection.
Of course, there is the need to test custom template tags and filters, for which (1) is an appropriate solution. However, this requires no additional framework to test - as evidenced by the fact that template tags are already tested as part of the 'othertests' package.
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 -~--~~~~--~~--~--~---
