Re: Proposal: default escaping
Am 14.06.2006 um 21:08 schrieb Jacob Kaplan-Moss:
[snip]
> Given that, I think the best idea is still using a block tag::
>
> {% escape %}
> {{ var }}
> {% endescape %}
I feel this is inelegant and insufficient. Back when this topic was
raised last time, I chimed in with a reference to how we handling
HTML escaping in Trac:
http://groups.google.com/group/django-developers/browse_thread/
thread/e448bbdd40426915/9962020f9699471c?q=lenz&rnum=8#9962020f9699471c
To reiterate: templates shouldn't need to care about escaping. Django
*in particular* uses an intentionally dumbed down template system
that is supposed to be easy for non-programmers, which includes the
notion that little mistakes in templates shouldn't break the site or
even introduce security holes.
IMHO, a real solution for this problem is that any normal string
inserted into template output is escaped by default. This does not
necessarily mean that there needs to be an unescape filter, though.
In fact, most of the time Django components that generate a string
they *know* that they are generating text that must not be escaped,
such as the output of the markdown filter, or form field render()
results. Those places should flag the strings they are generating in
some way (for example by wrapping them in a special class), thereby
signaling to the template system that those strings should not be
escaped again.
Now, I'll admit that the Django template engine being output-type
agnostic is a problem in this context. But then again, I'm not happy
with Django templating in general, so I'll just shut up now :-P
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~-~--~~~---~--~~
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? :)
Am 17.07.2006 um 16:59 schrieb Adrian Holovaty: > 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! You may want to manually escape the first_name/last_name in that example ;-) Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: [Fw]The Python Web Framework
Am 22.08.2006 um 18:22 schrieb James Bennett: > Some things that occur to me on other points: > > * Admin, auth and comments using Django's own ORM, template system, > etc.: well... what are we supposed to use? They're Django > applications, and they leverage as much or as little of Django as they > need to accomplish their goals. Also, it is possible to use another > ORM with Django and still use the admin app. You're taking the original statement out of context. The context was the often-heard argument that Django lets you replace any subsystem if you prefer using a different library. What's less often-heard is that if you do so, you are giving up a lot of the niceties that Django provides (such as the admin if you use a different ORM) > * Database connection pooling: not sure what's up with this. The > multi-db branch looks fairly stable, but that's not what comes to mind > when I think "database connection pooling", and what comes to mind > when I think "database connection pooling" isn't something I think > belongs in Django. Karl Guertin answered this one nicely I think. If you're providing a database access layer on top of the raw DB API, you should probably also provide connection pooling. I bet there's a ticket for that. > * Requiring DJANGO_SETTINGS_MODULE: I thought we fixed that so that > you could do most non-app things without having to provide a full > settings file[1]. Or did I misunderstand that? That change improved the situation, but you still need the "from django.conf import settings; settings.configure(...)" before using any other part of Django. That works, but still doesn't feel clean. > * Escaping in templates: Christopher presents an *extremely* one-sided > view of what's actually a fairly complex debate. There is no single > obvious solution to escaping. Possibly. What concerns me is that many in the Django team seemed to think escaping is the responsibility of the template author, yet the template author shouldn't be bothered with having to care about programming logic. I've yet to meet a designer who understands XSS attacks, but "x < y" they get. Maybe it's just me. What probably wasn't clear enough the post: I think the *benefits* of a solid auto-escaping approach are obvious, not necessarily how that's done. > * The template system in general: the template system "doesn't scale > down to a single developer"? I'm going to have to call BS on that, > because we've seen plenty of one-man projects. The template tag > decorators also make it a whole lot easier to write common sorts of > tags. I'm sorry, but if you have to scurry around multiple files just to implement and use a parameterized reusable snippet of HTML markup, that's > * The template system being "dumbed down" for designers? Going to call > BS on that too. The real complaint here seems to be that the template > system doesn't include a programming language, and personally I don't > think it should. If there are things that someone runs into that they > find themselves needing to use the same custom template tag over and > over again in many different projects, then that needs to be submitted > for possible inclusion in the default tags. > > [1] http://code.djangoproject.com/changeset/2927 > > -- > "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: [Fw]The Python Web Framework
Am 22.08.2006 um 18:22 schrieb James Bennett: > Some things that occur to me on other points: > > * Admin, auth and comments using Django's own ORM, template system, > etc.: well... what are we supposed to use? They're Django > applications, and they leverage as much or as little of Django as they > need to accomplish their goals. Also, it is possible to use another > ORM with Django and still use the admin app. You're taking the original statement out of context. The context was the often-heard argument that Django lets you replace any subsystem if you prefer using a different library. What's less often-heard is that if you do so, you are giving up a lot of the niceties that Django provides (such as the admin if you use a different ORM) > * Database connection pooling: not sure what's up with this. The > multi-db branch looks fairly stable, but that's not what comes to mind > when I think "database connection pooling", and what comes to mind > when I think "database connection pooling" isn't something I think > belongs in Django. Karl Guertin answered this one nicely I think. If you're providing a database access layer on top of the raw DB API, you should probably also provide connection pooling. I bet there's a ticket for that. > * Requiring DJANGO_SETTINGS_MODULE: I thought we fixed that so that > you could do most non-app things without having to provide a full > settings file[1]. Or did I misunderstand that? That change improved the situation, but you still need the "from django.conf import settings; settings.configure(...)" before *importing* any other part of Django. That improves the situation, but doesn't feel clean. > * Escaping in templates: Christopher presents an *extremely* one-sided > view of what's actually a fairly complex debate. There is no single > obvious solution to escaping. Possibly. What concerns me is that many in the Django team seemed to think escaping is the responsibility of the template author, yet the template author shouldn't be bothered with having to care about programming logic. I've yet to meet a designer who understands XSS attacks, but "x < y" they get. Maybe it's just me. What probably wasn't clear enough in the post: I think the *benefits* of a solid auto-escaping approach are obvious, not necessarily how that's done. > * The template system in general: the template system "doesn't scale > down to a single developer"? I'm going to have to call BS on that, > because we've seen plenty of one-man projects. The template tag > decorators also make it a whole lot easier to write common sorts of > tags. I'm sorry, but if you have to scurry around multiple files just to implement and use a parameterized reusable snippet of HTML markup, because the template system doesn't trust you can use functions and parameters, that's additional work you need to do. More code and coupling between code and the templates. If the template system simply allowed you to call functions, you could reuse presentation logic that way, without having to register tags. And you don't need to learn a whole new syntax for every template tag. > * The template system being "dumbed down" for designers? Going to call > BS on that too. The real complaint here seems to be that the template > system doesn't include a programming language, and personally I don't > think it should. If there are things that someone runs into that they > find themselves needing to use the same custom template tag over and > over again in many different projects, then that needs to be submitted > for possible inclusion in the default tags. Allowing the full expressiveness of a programming language (with control structure and all) is quite different from allowing real expressions. Django intentionally does allow the embedding of Python expressions, because the devs think/thought that designers would have problem with the syntax, so for me calling it "intentionally dumbed down" is not all that unfair. I'm not saying that a dumbed down template system is a bad thing... for example, for systems like TypePad etc where (untrusted) users edit templates over the web, what you can do in templates absolutely needs to be restricted, unless you want to allow them to take down the system. My point was that for teams that work on a web-app, where there's no real distinction between programmers and template authors, this actually does not help productivity. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: [Fw]The Python Web Framework
Am 22.08.2006 um 21:49 schrieb Christopher Lenz: > Am 22.08.2006 um 18:22 schrieb James Bennett: >> Some things that occur to me on other points: >> >> * Admin, auth and comments using Django's own ORM, template system, >> etc.: well... what are we supposed to use? They're Django >> applications, and they leverage as much or as little of Django as >> they >> need to accomplish their goals. Also, it is possible to use another >> ORM with Django and still use the admin app. > > You're taking the original statement out of context. The context was > the often-heard argument that Django lets you replace any subsystem > if you prefer using a different library. What's less often-heard is > that if you do so, you are giving up a lot of the niceties that > Django provides (such as the admin if you use a different ORM) [snip] Sorry, this reply got sent before it was ready :-P For some reason I keep hitting "Send" when I mean "Lookup in Dictionary" :-P Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Integrating Django and SQLAlchemy
Am 31.08.2006 um 05:34 schrieb Adrian Holovaty: > On 8/30/06, Jay Parlar <[EMAIL PROTECTED]> wrote: >> A question then: Once the SQLAlchemy stuff is in and solid, will >> there >> be any reason *not* to use it? > > We'll decide that when we get there, but I'm inclined to answer your > question with a single word: "Simplicity." Django will continue to > work out of the box, with no dependencies. "No dependencies" is just one part of simplicity :-) Moving Django to SQLAlchemy wholesale would get rid of (or at least simplify) much of the DB code in Django. Adding SQLAlchemy support as an option is likely to increase the complexity of the code, and you basically have two different code paths to the database... patching and testing gets harder, understanding the code gets harder, writing and understanding the documentation gets harder. It's definitely a good idea to develop SQLAlchemy support as an optional alternative to the built-in ORM for now. But if the project works out, replacing the built-in DB code with SQLAlchemy is going to make a *lot* of sense IMO. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Ticket spam
Am 25.10.2006 um 11:24 schrieb Michael Radziej: > Adrian Holovaty schrieb: >>> Also, I've been mulling over the idea of requiring an account signup >> in order to post tickets and comments. Would that be worth the pain? > > I wouldn't mind to have to sign up before I could submit a > ticket, but it seems there's no automatic sign-up in trac. That > would be a nuisance. Multiple options here, all plugins: 1. <http://trac-hacks.org/wiki/AccountManagerPlugin> Allows you to switch to a setup where users can register and get a real account. Also provides form-based login. 2. <http://trac-hacks.org/wiki/TicketDeletePlugin> Allows people with TICKET_DELETE permissions to delete complete tickets, or (more interestingly) revert individual changes to tickets. This requires the WebAdmin plugin to be installed. Also, using the BadContent black-listing more effectively (read: update it more frequently) would get rid of a lot of spam I'm seeing on Django. I'd recommend giving out more accounts to (trusted) people who volunteer doing spam cleanup, allowing them to revert spam changes (using the TicketDelete plug) and add stuff to BadContent in a more timely manner. The SpamFilter plugin has optional IP-blacklisting which can help reduce many kinds of spam, too. I have no idea whether that's enabled on code.djangoproject.com. BTW, is the Akismet filter disabled now? Hope that helps, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: DecimalField
Am 25.10.2006 um 00:25 schrieb Jason Davies: > I am working on an application which deals with monetary values and it > *really* needs proper support for decimal, fixed-point (as opposed to > floating-point) values. > > See: http://code.djangoproject.com/ticket/2365 > > Could someone take a look and get this patch approved? > > I think we should just distribute decimal.py to maintain Python 2.3 > compatibility. Oh come on, just let Python 2.3 users install the decimal module from SF: <http://sourceforge.net/project/showfiles.php? group_id=104148&package_id=130611&release_id=291663> I'd also suggest keeping FloatField as it is (i.e. half-broken, depending on DB backend, or fix it to always return floats, but that's break backwards compatibility again), deprecate it, and introduce the new DecimalField. Only the use of DecimalField would require the decimal.py module, same as ImageField requires PIL. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Ticket spam
Am 25.10.2006 um 17:22 schrieb Christopher Lenz: > Am 25.10.2006 um 11:24 schrieb Michael Radziej: >> Adrian Holovaty schrieb: >>>> Also, I've been mulling over the idea of requiring an account >>>> signup >>> in order to post tickets and comments. Would that be worth the pain? >> >> I wouldn't mind to have to sign up before I could submit a >> ticket, but it seems there's no automatic sign-up in trac. That >> would be a nuisance. > > Multiple options here, all plugins: FYI: Akismet has been having a really high rate of false positive lately, we've seen the same problems with it at trac.edgewall.org. I've filed a support request but haven't heard back. Anyway, this whole issue has provoked me to completely overhaul the Trac SpamFilter plugin today. It's now based on a Karma/Score system that lets you fine tune how much of an effect any single spam filter "strategy" has on the overall outcome. Using the default values, when a user sets up their name or email address on the settings screen, that would overrule an Akismet spam response. Also, the plugin now provides much better means for monitoring what's going on. And more to come very soon (traiing, anyone?) Probably worth a try for code.djangoproject.com, and IMHO better than requiring registration and a password just to file a ticket. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Ticket spam
Am 27.10.2006 um 00:35 schrieb Christopher Lenz: > FYI: Akismet has been having a really high rate of false positive > lately, we've seen the same problems with it at trac.edgewall.org. > I've filed a support request but haven't heard back. > > Anyway, this whole issue has provoked me to completely overhaul the > Trac SpamFilter plugin today. It's now based on a Karma/Score system > that lets you fine tune how much of an effect any single spam filter > "strategy" has on the overall outcome. Using the default values, when > a user sets up their name or email address on the settings screen, > that would overrule an Akismet spam response. Also, the plugin now > provides much better means for monitoring what's going on. And more > to come very soon (traiing, anyone?) > > Probably worth a try for code.djangoproject.com, and IMHO better than > requiring registration and a password just to file a ticket. Continuing the monologue... See: <http://www.cmlenz.net/blog/2006/11/managing_trac_s.html> We're now running 0.10dev and SpamFilter 0.2dev on edgewall.org (for the Trac and Genshi projects). The Akismet filter is pretty much disabled since yesterday due to Akismet still being a bitch. We currently rely mostly on SpamBayes, IP blacklisting, and simply counting external links. SpamBayes is trained with about 25 ham and spam submissions, each. Results so far: zero false positives and not a single spam submission getting through, while stilling allowing anonymous users to submit content. And spammers are hitting us at a rate of between 50-100 submissions per hour (which doesn't include those manually blocked by IP that Trac doesn't even see, which would multiply that number). I'm sure the spam bots will grow smarter and get around these measures at some point, but it'll take them some time (judging by how primitive they are right now that'd be a long time.) I'm not sure what the spam situation on code.djangoproject.com is right now, but in any case I'd recommend you guys do update to 0.10 and install the new SpamFilter. Feel free to ping me (cmlenz on #trac) if you have any questions. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: ANN: Django's Trac installation has been upgraded
Am 06.11.2006 um 18:43 schrieb Jacob Kaplan-Moss: > I know that a few things on the code site are still broken or > looking ugly; > I'm stupid when it comes to upgrading Trac and I always seem to break > templates. I'll be working on that throughout the day. Great to see you've upgraded :-) About template breakage: we generally recommend that you make as few changes/overrides to the templates as absolutely necessary, for exactly the reason that such changes make upgrades harder. You can do a lot using only the site_css, site_header, and site_footer templates in the environment "templates" directory, and leaving all the other templates alone. You can also have a site_newticket.cs template to guide people when creating new tickets with some introductory text. More info on this topic here: <http://trac.edgewall.org/wiki/ TracInterfaceCustomization> Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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 site: Trac e-mails not including comments
Hi Adrian, Am 07.11.2006 um 17:51 schrieb Adrian Holovaty: > It looks like the recent Trac update for code.djangoproject.com has > caused a negative side-effect: The e-mails sent out to django-updates > no longer include any changes to a ticket's comments. > > Any Trac experts out there know how to fix this? Please check whether you have a ticket_notify_email.cs template in your environment directory. If you do, delete it. (And as I mentioned before, it'd be a very good idea to also delete the other templates from that directory and move all customizations local into the various site_xxx.cs templates.) If that doesn't solve it, check the global templates directory (usually under /usr/share/trac/templates) and verify that the timestamps correspond roughly to the time you upgraded. If they're too old, maybe the upgrade didn't overwrite the templates for some reason. In either case, this issue has already been reported here: <http://trac.edgewall.org/ticket/4067> Please append your findings and configuration to that ticket. The more info we have about this, the better :-) That said, mail notifications from various projects that use 0.10 are working rather nicely, so I'd be surprised if this was an actual bug in Trac. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: JS Form Validation (was Re: Django and AJAX: Setting aside the conflict)
Am 17.11.2005 um 10:07 schrieb Simon Willison: On 17 Nov 2005, at 05:48, David Ascher wrote: Goofy idea: use the Python logic to generate JS code to do clientside validation based on the model-specified constraints. Detailed specification and implementation are left as an exercise to the reader. ;-) Here's a concept for form validation with Ajax I've been knocking around for ages that I would love to see in Django. The most annoying thing about client-side validation is having to duplicate the logic used in your server-side validation code. Automating this is a nice idea but suffers from a couple of pretty big problems: 1. Differences between JavaScript and Python regular expression syntax 2. Some checks, such as "is this user name already taken", can only happen with server involvement Here's how to fix both of these: have the client-side validation run against the server-side validation logic using Ajax to communicate between the two. While there are definitely many types of validations that can't be performed on the client side, calling back to the server just to check whether e.g. a text-input is empty is overkill IMO. The same goes for validity checks for common things like text fields expecting an email address or date. I'd prefer a hybrid approach, where simple javascript validation checks are generated, and the others are performed via AJAX callbacks. Associate a pre-written (generic?) view with that end point that is itself associated with a set of validation rules - in Django terms that would probably be a manipulator of some sort. Every time a form field is filled in the blur event causes JS to post the field name and the data from that field at the validate endpoint. It returns a simple JSON object representing if the data was valid, invalid or undetermined (for fields which can't be validated without seeing information from elsewhere in the form - we probably don't want to send all form field data at once for every validation call as forms involving big textareas can end up with a lot of data in them). Invalid responses are accompanied by a JSON array of human readable error messages. Validation starts to get interesting when it involves relations between multiple field, for example one field must be non-empty and contain a date, but only if some checkbox is checked. It'd be interesting if such relations could somehow be expressed, so that the server callback would get all the data it needs for the validation, and not more. OTOH, the validation in this example would ideally not even get triggered, because the date text field would be disabled until the checkbox got checked :-P A better example is probably the classic "matching passwords" validation. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/
Re: JS Form Validation (was Re: Django and AJAX: Setting aside the conflict)
Am 17.11.2005 um 23:29 schrieb Antonio Cavedoni: On 17 Nov 2005, at 11:51, Christopher Lenz wrote: While there are definitely many types of validations that can't be performed on the client side, calling back to the server just to check whether e.g. a text-input is empty is overkill IMO. The same goes for validity checks for common things like text fields expecting an email address or date. I'd prefer a hybrid approach, where simple javascript validation checks are generated, and the others are performed via AJAX callbacks. I don’t agree with this approach. While I think client-side validation is fine and dandy, and from a user perspective is definitely the way to go, we cannot rely on it. Well, it goes without saying that server-side validation is *always* required. AJAX or not. We also don’t want to have to mantain the same code in two places: email-validation in JS on the client and email-validation on the server (yes, I’m oversimplifying, but you get the idea). I don't agree, at least for the common cases such as validating emails, URLs, date/time fields etc. It really shouldn't be necessary to call back to the server for trivial and/or common validation tasks. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/
Status of magic-removal
Hey folks, We've just started a new project here with Django and decided to build it on top of the magic-removal branch, since the project is going to be worked on for a couple of months. Now, actually using the magic-removal is currently raising more problems than I had hoped. I've been looking into the code and trying to write and submit patches as I find problems that are easy enough to figure out, but most problems are beyond my current knowledge of the Django code, and more importantly, beyond my understanding of the design objectives of the branch. I.e. I'm fully prepared to get my hands dirty with the code, but need a bit more guidance :-P For example, <http://code.djangoproject.com/ticket/1330> is pretty much a show-stopper here. Any hints on what kind of changes would be needed to fix edit_inline on magic-removal? Other issues include the broken content-types stuff (#1280... why's that patch not checked in yet?) and thus broken "Show on site" links and generic views (IIUC). Also, some of the unit tests are failing... is that expected? Anyway, I'd be very grateful for an overview of the status of the branch, e.g. what major design issues still need to be solved and what work might need to be done that people simply don't have the time to do (and what, roughly, would be involved). Thanks, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: DoJo Integration & JSON methods
Am 09.02.2006 um 15:34 schrieb Jacob Kaplan-Moss:
> On Feb 9, 2006, at 2:55 AM, Ian Holsman wrote:
>> a while back Euguene mentioned on djnago-users that 0.92 will have
>> dojo ajax components in the admin interface.
>>
>> is this being developed on a seperate branch?
>> I'd like to talk about the json layer, and how a common method for
>> sending errors in validation/processing to the front end could work.
>>
>> basically in the code i have I am passing a json object like
>> { result: true/false and messasge: 'error message' }
>> which then gets displayed to the user if it requires.
>
> Hi Ian --
>
> I've been working on the Dojo stuff in my own sandbox. Right now
> the admin is broken pretty bad while I'm redoing all the ad hoc JS
> bits, so I've not yet checked anything in (I hate checking in
> broken code).
So how about a branch ;-)
Anyway, does this work include some sort of "HTMLField" that renders
using Dojo's HTML editor?
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~-~--~~~---~--~~
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: Validation-aware models
Am 22.02.2006 um 08:12 schrieb Adrian Holovaty: > Let's return to this subject, which was discussed a couple of weeks > ago. Here's my latest thinking on the subject. > > * Automatic manipulators go away. Instead of messing with those, to > create a new model object you try instantiating it. Validation errors > are raised at that point. Example: > > try: > c = Crime(crime_date='2006-1-2', crime_type='theft') > except ValidationError: > print "You have errors." > > # Getting the errors > > try: > c = Crime(crime_date='2006-1-2', crime_type='theft') > except ValidationError, e: > print e.messages # prints list of error messages (as strings) > > * Specifically, validation happens on Model.__init__() and > Model.__setattr(), except when model objects are being loaded from the > database (e.g. Model.objects.get()). In the latter case, we can assume > the data is valid. Why not do the validation on Model.save(). The developer can not "forget to validate", but the model instance is allowed to be invalid temporarily, until it is fully populated and actually gets saved. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Validation-aware models
Am 23.02.2006 um 11:04 schrieb Robert Wittams: > * The hack fields like auto_now and auto_now_add will need a > rethink. I > really don't have much of an idea what you can do to make these > sensible. Some callback on .save() maybe. I've been wondering about this one... SQLObject allows you to use a function for the default value, the equivalent in Django would be: created = models.DateTimeField(default=datetime.now, editable=False) The function is invoked when the object is prepared for insertion. This would be a cleaner and more general approach to implementing auto_now_add behavior IMHO. Of course that doesn't address auto_now, but personally I wouldn't have a problem with updating such a timestamp field in the overridden save() method. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Status of magic-removal
Am 21.02.2006 um 22:58 schrieb Jacob Kaplan-Moss: > I, for one, want to get m-r wrapped up and merged back to trunk as > soon as humanely possible. I feel like it's starting to be a drag on > new users trying to figure out why development on trunk seems to have > stopped, and I want to get us all back to one codebase. I agree 100% with that goal... but I'm curious on how you want to get there. In its current state, magic-removal is severely broken in many significant ways. Don't get me wrong, I'm a big fan of the general direction of the branch... the "magic modules" part of Django was really a turnoff for me before. To an outsider like myself, it looks like there's been a rush towards a major refactoring that (pretty much) stopped somewhere along half the way, leaving quite a number of those features that make Django such a great framework non-functional. And there's no documentation (and only sparse archived discussion) about how the currently broken functionality should be fixed... otherwise I'd have contributed a good share of patches by now. IMHO, what the Django community needs at this point is for someone in the know to update the RemovingTheMagic page, and add meat to the "What's not done yet" section. Limit the scope of the branch, point out what areas need fixing and how those are supposed to be approached. I'm sure the "masterplan" is somewhere in the heads of the developers, but it needs to be communicated to users and potential contributors if we are to test and contribute to the branch. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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
Am 28.02.2006 um 15:58 schrieb hugo: >> I'm not sure exactly what reparations you're thinking will be >> possible >> by rolling back a DDL transaction. I'm pretty sure most db's don't >> have full transaction control over DDL. Issuing a DDL statement >> usually involves at least an implicit commit, so, e.g., if something >> goes wrong three DDL commands into your evolution you're not going to >> be able to roll back to initial state. > > PostgreSQL and SQLite fully support transactioned DDLs. Actually, PySQLite 2.x does an implicit commit after any DDL statement. I don't think this is enforced at the SQLite level, but supposedly the PySQLite author had reasons to do this in the bindings. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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
Am 28.02.2006 um 21:39 schrieb Jeremy Dunck: > On 2/28/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: >> Actually, PySQLite 2.x does an implicit commit after any DDL >> statement. I don't think this is enforced at the SQLite level, but >> supposedly the PySQLite author had reasons to do this in the >> bindings. > > Do you know what the reasons were, or where we should look for them? I'm not really sure, here's the code that does it: http://initd.org/tracker/pysqlite/browser/pysqlite/trunk/src/ cursor.c#L509 ... which just says "to be safe" :-P Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: templates and html escaping
Am 03.03.2006 um 18:53 schrieb Jacob Kaplan-Moss:
> Hey folks --
>
> I've thought about this a bit more; lots of good points have been
> raised. What I'd like to do would be to add a new tag that takes
> care of auto-escaping variables used within it. Something like::
>
> {% autoescape %}
> Any {{ variables }} used within this {{ block }} will be
> automatically {{ escaped }}
> {% endautoescape %}
>
> How does that sound?
Not quite enough IMHO.
I strongly agree with some of the other posters in this thread that
any kind of output in an HTML-template should be HTML-escaped by
default. Values that contain markup that should not be escaped should
be flagged explicitly.
In Trac 0.9.3 we added exactly this kind of behavior to greatly
eliminate the risk for XSS vulnerabilities. See:
<http://projects.edgewall.com/trac/browser/trunk/trac/util.py#L56>
When the template engine sees a value that is a str/unicode, it gets
escaped. If it gets a value that's an instance of the "Markup" class,
it gets passed through as-is.
Adding such behavior to the Django template processor would be great.
It's *much* easier to forget to escape something than to forget to
flag it as not-needing-escaping.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Fixing edit_inline on magic-removal
Hey Djangonauts, I've attached a patch to ticket #1330 that fixes the edit_inline support: <http://code.djangoproject.com/ticket/1330> The "brokeness" of edit_inline on MR is IMHO the major area that makes the branch unusable to many people. The patch reverts some changes (such as the removal of core fields) which were never really completed. While I'm aware that a much improved version of edit_inline is on the way (using Dojo/AJAX and all that), I think that the branch should be merged back into trunk before that work is finished, i.e. that that stuff happens on a new branch after magic-removal has been merged. So I hope this patch helps moving the MR branch a bit closer to the merge. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Validation Aware Models and django.forms on steroids
Am 08.03.2006 um 16:20 schrieb Joseph Kocherhans:
> The short version of this is really, forms and manipulators merge and
> get more powerful, models grow validation. This is an attempt to
> clarify and add to Adrian's previous proposal. I hope it takes care of
> people's concerns. Here are some details:
>
> Forms and FormFields are intended to be used for web applications
> only. Models do validation, so using forms isn't necessary when
> manipulating data directly in python. Also, I think something similar
> to this would allow for recursive forms (edit_inline behavior), but I
> haven't worked out all the details.
>
> Models would grow a validate method and validate=True is added as an
> argument to Model's save methods. Models would not do any type
> coercion. (I guess they could, but I think most type coercion should
> happen in the form fields, not the model fields.)
Agreed. Models should expect the correct Python types, coercion from
strings/whatever should be in the web layer.
> I'm ignoring a bunch of metaclass magic that needs to go on here, but
> I hope the intentions are clear. Bring on the pseudocode...
>
>
> class Form(object):
> def __init__(self, request, prefix=''):
> self.request = request
> # prefix corresponds to a prefix to http variable names.
> The prefix
> # should be used to strip off the first part of the var names.
> # Hopefully this will allow for recursively defined
> forms... in other
> # words, edit_inline is available outside of the admin system.
> self.prefix = prefix
> # this would actually be more complicated... use prefix to
> get a dict
> # of strings for the form fields to coerce.
> self.data = request.POST.copy()
>
> def _get_model_obj(self):
> """
> return the cached model object, or init/cache/return one.
> """
>
> model = property(_get_model_obj)
So how is a Form connected to a Model?
> def set_defaults(self):
> """
> Call get_default() (hopefully passing in self.request) on each
> FormField, and set the appropriate attributes on self.model.
> """
>
> def validate(self):
> """
> Basically just return self.model.validate(). Call validate
> for child
> forms as well.
> """
>
> def save(self, validate=True):
> """
> Basically just call self.model.save(validate=validate) Call
> save for
> child forms as well.
> """
>
> def html(self):
> """
> This is really just convenience for people who are too lazy
> to write
> real templates. Returns a very generic form redered as
> html. It
> should probably have enough css hooks to make it workable
> though. It
> is meant to be called in a template like {{ form.html }}
> """
Maybe this would be better implemented as a template tag?
> class ArticleAddForm(Form):
> # author will not be editable or displayed
> exclude_fields = ('author',)
> extend_fields = (
> formfields.EmailField(field_name="from", is_required=True),
> )
>
> class ArticleChangeForm(Form):
> # author will be displayed, but not editable
> readonly_fields = ('author',)
>
> class Article(models.Models):
> name = models.CharField(maxlength=100)
> body = models.TextField()
> author = models.AuthorField()
>
> class Meta:
> # this gets used in generic create views
> add_form = ArticleAddForm
>
> class Admin:
> # this gets used in the admin system
> change_form = ArticleChangeForm
>
>
> # Usage:
> def myview(request):
> add_form = Article.AddForm(request)
> errors = add_form.validate()
> if not errors:
> add_form.save(validate=False)
> return HttpResponseRedirect('the_next_page')
> ctx = RequestContext({'form': add_form})
> return render_to_response('template', ctx)
>
>
> I hope something like this will come out of Adrian's validation aware
> model proposal. This would solve those issues, and add a ton of
> flexibility to Django. There are many details that need to be pinned
> down, but I think something like this should be workable.
>
> Also, there are things that I've probably overlooked. What are they?
I've probably missed some of the previous discussion, but does all
this mean that Manipulators would go away completely?
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~-~--~~~---~--~~
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: Fixing edit_inline on magic-removal
Am 08.03.2006 um 21:06 schrieb Tom Tobin: > On 3/8/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: >> The patch reverts some changes (such as the removal of core fields) >> which were never really completed. While I'm aware that a much >> improved version of edit_inline is on the way (using Dojo/AJAX and >> all that), I think that the branch should be merged back into trunk >> before that work is finished, i.e. that that stuff happens on a new >> branch after magic-removal has been merged. > > While I'm a *huge* advocate of getting MR wrapped up and merged before > it achieves sentience and takes over half the Internet, I'd rather > have any breakage happen here and now rather than post-merge. I hate > to say it, but a feature-freeze date for MR may be in order: if > something backwards-incompatible hasn't been proposed and agreed upon > before then, it doesn't go (and gets postponed to trunk, perhaps for > post-1.0), and everything post-freeze is pure implementation and > bugfixes. There's the danger of a branch that never merges, because it has too many issues to get enough exposure with users (and in turn doesn't get enough exposure to enable all the issues to get discovered and fixed). I'm all for a feature-freeze for MR: IMHO the remaining bugs should be fixed, and the contrib apps (such as comments) updated to the new API, but *before* there's any more major refactorings. Make another minor release, and push -- for example -- validation-aware models and a Dojo-enhanced admin to the next minor pre-1.0 release. Release often, release early. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Start of week in Admin's calendar
Am 13.03.2006 um 08:27 schrieb Adrian Holovaty: > On 3/9/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: >> I was porting javascript calendar from Admin into my application and >> enhanced it a bit with new boolean pref switching start of week to >> Monday. To submit this to Django I want to hook this pref somehow to >> i18n settings but have no idea where it should be and how it's better >> done in Django. Any pointers? > > Cool, that sounds like a nice improvement! > > I think the best (and simplest) way to hook this into Django would be > a setting. Something like FIRST_DAY_OF_WEEK = 1. In that case, how would you make this dependent on the locale of the remote user? Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Validation-aware models: First stab
Am 13.03.2006 um 08:00 schrieb Adrian Holovaty: [snip] > Thoughts, criticisms? The only part I'm sketchy on is the side effect > of converting the values to their Python data types. The > cleanliness/consistency is quite nice, but it's slightly not something > a developer might expect. However, we can solve the latter through > clear documentation. IMHO automatic conversion from strings to python types shouldn't be in the model layer. Model fields should expect to get a compatible type (at least directly castable to the target type, such as int (floatnum) or str(intnum)). I could even imagine a DateTimeField accepting a timestamp or time tuple... but parsing out the date from a string seems like a step too far. The form/manipulator should be doing that kind of conversion. Also, the names validate() and validate_full() had me confused for a bit until I read the code. IIUC, validate() is the internal interface for subclasses, while validate_full() is the external interface invoked by the Model class. But that's rather non-obvious from the names ;-) Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Validation-aware models: First stab
Am 15.03.2006 um 07:39 schrieb Russell Keith-Magee: > Addressing the arguments against:: > 1) Validation shouldn't be in the model > > If validation isn't in the model, then the model is little more > than a light data container; if all you have is a light data > container, then the onus is on the user to ensure that validation > conditions are checked and rechecked whenever they are used (which > smacks of code duplication to me). Putting validation right in the > model means that it is never missed. I definitely agree that the model layer should do validation, as long as that doesn't mean it's the *only* layer that does validation (that's not how I understood the proposal, but some some of the comments seemed to imply that). I may have forms that don't map 1:1 to models; for those, parts of the validation must be done by the formwrapper/manipulator, and other parts by the model classes. > 2) Instantiation shouldn't be from string > > Adding string instantiation just seems straight up powerful. Push > data in in any meaningful format, and it will get converted (if > possible) to the internally preferred representation. Some have > called this 'magic' - to me, it's just being liberal in what you > accept, but conservative in what you produce. That phrase is about network protocol implementations, I don't think it applies equally to programming interfaces ;-) There's a thin line here between convenient auto-conversion (e.g. strings to numbers) and overloading the model class with logic that simply doesn't belong there. In your web layer code, you have something akin to a manipulator sitting between your model classes and the view. The manipulator would be responsible for unmarshalling POST parameters into a data structure that can be handled by the model, including parsing stuff like dates and exploding "dotted" parameters into nested dicts or whatever. > There have been some interesting proposals for separating > 'instantation from data' from 'instantiation from string'; While I > understand the sentiment, I'm just not sure they're worth the > effort. The only use case I can see here is if the way a string is > interpreted will vary depending on the data source, but I don't see > this as very likely (or even advisble). Example: the string representation of a date in may depend on the locale of the remote user, which the model knows nothing about. The conversion from string to datetime will need to happen in a layer that is aware of the HTTP request context. (This is a somewhat contrived example due to the abysmal state of international datetime formatting/parsing in the Python standard library, but I'm sure there are other examples). Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Validation-aware models: First stab
> On 3/15/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: >> I definitely agree that the model layer should do validation, as long >> as that doesn't mean it's the *only* layer that does validation >> (that's not how I understood the proposal, but some some of the >> comments seemed to imply that). I may have forms that don't map 1:1 >> to models; for those, parts of the validation must be done by the >> formwrapper/manipulator, and other parts by the model classes. > > The model layer certainly isn't the *only* layer that does validation. > Of course, Django will continue to support custom forms and validation > logic on a level that's decoupled from models. > >> There's a thin line here between convenient auto-conversion (e.g. >> strings to numbers) and overloading the model class with logic that >> simply doesn't belong there. In your web layer code, you have >> something akin to a manipulator sitting between your model classes >> and the view. The manipulator would be responsible for unmarshalling >> POST parameters into a data structure that can be handled by the >> model, including parsing stuff like dates and exploding "dotted" >> parameters into nested dicts or whatever. > > Right -- that's exactly what will happen. > >> Example: the string representation of a date in may depend on the >> locale of the remote user, which the model knows nothing about. The >> conversion from string to datetime will need to happen in a layer >> that is aware of the HTTP request context. (This is a somewhat >> contrived example due to the abysmal state of international datetime >> formatting/parsing in the Python standard library, but I'm sure there >> are other examples). > > In this example, the view code would perform that logic -- not the > model layer. The model layer is only responsible for *critical* > validation logic that applies to *every instance of the model, ever* > -- not special-cases. For special cases, you'll use a custom > form/manipulator, just like before. Thanks for the clarification... matches my understanding of the proposal, I just had the feeling there was some confusion about these points in this thread (e.g. Model.html2python, which is what manipulators are for). Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Magic-removal query syntax
Am 19.03.2006 um 08:12 schrieb Max Battcher:
> Russell Keith-Magee wrote:
>> You still need to parse kwargs to handle queries across joins (e.g.,
>> Article.objects.filter(author__name__exact='fred'))
>
> Just playing around with ideas, but what if you could do something
> like:
>
> Article.objects.filter(author=Author.objects.filter(name='fred'))
Fairly ugly, that :-P
Has something like the following syntax been discussed here before?
Article.objects.filter(Article.author.name == 'fred')
Article.objects.filter(Article.author.name.contains('fred'))
etc
(overloading operators of the field descriptors to make this work)
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
More specific CSS rules for the admin
Hi all, (this one is mostly for Wilson, I guess) I see there's been some refactoring of the CSS for the admin app going on, so this might be a good time for a related change: Many of the style rules used in the admin CSS have very generic selectors (there are styles for p, ul, etc). In my current project, we're embedding the admin screens in our own layout, reusing the styles for the rest of the site. The generic rules in the admin CSS make that a lot more cumbersome than it'd need to be. I'd really like to see the selectors changed to be more specific (for example, use ".admin-form p" instead of just "p"). Also, the the markup use some class and ID names that are fairly common, such as #content. These are pretty much guaranteed to clash with names used for the site layout. Could those be changed/prefixed (for example, "#admin-content" instead of "#content"). Those changes would make it a lot simpler to embed the admin app in an existing layout. Thanks, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: More specific CSS rules for the admin
Am 07.04.2006 um 18:30 schrieb Rudolph: > It could be solved by putting the django-admin stuff inside a tag with > a django-admin class. Then ".django-admin p" or ".django-admin > #content" will format only the admin stuff and not your site. No, because the admin style sheets use "p" as a selector, and not ".django-admin p". Thus, the admin styles also affect stuff outside the admin itself, which was exactly my point. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: More specific CSS rules for the admin
Am 07.04.2006 um 17:03 schrieb Wilson Miner: > I'm open to being convinced otherwise, but I don't see it as within > the scope of the admin CSS to accomodate being embedded in other > interfaces. > > We've discussed this internally before and the general consensus was > that if you're reusing the admin templates and code in your public > site (which is great), you should be encouraged to restyle it for your > site rather than using the default CSS. I realize I might not have made clear enough what I'm trying to do here... I'm working on a site where the customer is going to be managing the content. The management interface is basically the Django admin app, with a couple of custom fields and a custom base.html template. While the admin is not something that the general public will see, we still consider it important that the management interface reflects the design of the site in general. I.e. just using the Django admin with a branding logo in the upper left corner doesn't quite cut it. On the other hand, the styles for the tables, forms and widgets are great and usable as-is, and I'd really like to reuse instead of duplicate them. > The templates themselves are designed (or should be designed) to be as > semantic and design-agnostic as possible, so you're not tied to using > the admin design in your public sites. I want to use the admin design, just not the generic stuff (fonts, colors, etc). Restyling all the admin forms and widgets would be a *lot* of work. The other option would be using a different markup structure and style sheet for the admin than for the rest of the site. But I'm wary of the duplication here, too... two different ways to achieve the same resulting layout. > Again, I'm open to compelling arguments otherwise, but I don't want to > overload the admin CSS with too much specificity and redundancy to > encourage modular reuse. I think it's a good goal that the templates > should be as reusable as possible, but I'm not convinced that the > styles should be. Okay, I understand the concern about being overly specific in the markup and the style sheets. So here's a suggestion: what about splitting out the generic layout styles from the styles for the change-lists, change-forms, widgets etc? Then I could simply drop the reference to the layout style sheet from the base.html template, but still keep the other stuff. Or is that already possible with your recent changes? Thanks, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: More specific CSS rules for the admin
Am 10.04.2006 um 17:28 schrieb Wilson Miner: > That should be possible with the changes to stylesheets in magic- > removal. Almost, but not entirely. Observe: <http://code.djangoproject.com/browser/django/branches/magic- removal/django/contrib/admin/media/css/global.css> This mixes completely generic styles (which I don't want) with admin- specific styles (which I do want). Do you see a chance of splitting that up further, for example by moving the generic styles into "layout.css"? I can experiment with this a bit and report back if I find a simple solution. > Also, nothing should be preventing you from copying the admin styles > and modifying them to be specific to your own needs. Sure, but that'll leave me with merging headaches when I want to upgrade Django and the style-sheets have been modified :-P Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Ned Batchelder's hyphenate
Am 11.07.2007 um 07:49 schrieb [EMAIL PROTECTED]: > I welcome any and all help!!! I don't see this as anything crucial or > time sensitive. > For my part I want this feature for a project, and at worst can > include the code as an app there. I just believe it should be part of > the django distribution instead of some third party addon. Um, you do realize that you don't normally need any kind of hyphenation in web applications? Personally, while I love that Ned's coded this thing because I happen to need it for one of my current projects, I don't see it as a need common enough for inclusion in Django, or even a Django contrib thing. If you want to build on Ned's work and extend it so that it's properly internationalized and all that, just make it a separate project. Most of the time, the projects where you may need hyphenation aren't even web applications, so including the functionality in Django would be rather inconvenient for those. And doing this stuff as a separate project does not in any way preclude using it in a Django app. Just my 2 cents. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Shouldn't _ be ugettext instead of gettext?
Am 15.08.2007 um 16:52 schrieb Michael Radziej:
> currently, django/conf/__init__.py still sets __builtins__['_'] =
> gettext.
>
> This causes a UnicodeDecodeError in code like the following line
> when the
> the translated message contains non-ASCII characters:
>
> _('some message: %s').someModel.name
>
> Shouldn't _ better evaluate to ugettext?
See also <http://code.djangoproject.com/ticket/5056>
(I still don't see why you'd ever want the bytestring variants of
gettext, but don't want to waste any more time arguing about this
stuff).
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[ANN] Babel/Django integration
Hey folks, you may be interested in a contrib package I've added to the Babel repository, which enables using Babel from a Django app. See: <http://babel.edgewall.org/wiki/BabelDjango> It adds middleware and template filters. Also, there's a message extraction plugin for Django templates. I'd suggest anyone interested in i18n in Django have a look at the extraction stuff, I think it may be quite interesting to use it instead of the hacked together xgettext glue scripts currently employed by Django. If you're interested, please feel free to ping me on #python-babel on freenode, or the Babel mailing list. Oh, and kudos to Ramiro Morales and Massimo Scamarcia for contributing the middleware and extraction code! Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: A question about manage.py validation
Am 21.08.2007 um 04:54 schrieb Marty Alchin: > On 8/20/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: >> There is indeed a reason: model field validation logic is in a >> separate module so that the logic doesn't have to be loaded into >> memory when you're using Django in production. As it stands, the >> validation code is only loaded when you use one of the relevant >> manage.py commands. Validation really only matters when you're >> developing. [snip] >> We *could* have our cake and eat it too, by adding a validate() >> method >> hook to the database Field class and have the default implementation >> import the full validation logic from another module. This would let >> people implement their own validation logic for custom fields. This sounds very much like premature optimization to me. Is the additional memory required by the validation logic really noticeable? For example, how does the it compare to having all of newforms loaded (even though you may only use 3 different types of fields/widgets on your site), or all the default template tags and filters? Etc etc. Designing with performance in mind is a good thing. But if you start sacrificing the quality of your design, without actually having measured that the optimization really makes a noticeable difference, that's "the root of all evil", as they say. > I have to admit I'm a little reluctant, but I don't have enough > experience with memory optimization to counter your reasoning. It > seems cleaner to me to have these done in each Field's __init__, but > that would indeed force that to happen every time the server starts, > regardless of development status. Um, is this about invoking the validation code, or just about having it loaded in memory? Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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, Components, and Interfaces
Am 07.09.2007 um 20:40 schrieb Yuri Baburov: >> Or if I'm using Satchmo and I've written an excellent CRM system >> in Django, >> I want Satchmo to use the shipping and contact information that >> I've defined >> in my CRM system, and if they both implemented IPerson, >> IPostalAddress, and >> IPhoneNumber, I could drop in those replacements. Without that, >> I'm bound to >> either duplicate my data across the two applications, hack Satchmo >> to use my >> CRM, or constrict my CRM system to require Satchmo. > I can see abstract idea. But don't see right implementation idea. > 1) You can do this all without all javaish interfaces. > Python metamodel is open for changes when program is running. > 2) Interfaces are not python way of doing stuff. google: duck typing. > Please take my arguments into account and reconsider your idea with > them. Except that interfaces in Trac's component system (and AFAIK also in Zope or PyProtocols) aren't about typing *at all*; they're about protocols for using, extending, or replacing functionality (components). It might help to actually read up on stuff before commenting. For your convenience here's a link: <http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture> (I'm not really going to weigh in on whether this whole thing would be a good match for Django, just defending a design against uninformed comments; I'm also not saying that the design is in anyway perfect; there's definitely room for improvement). Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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, Components, and Interfaces
Am 07.09.2007 um 21:07 schrieb Christopher Lenz: > Am 07.09.2007 um 20:40 schrieb Yuri Baburov: >>> Or if I'm using Satchmo and I've written an excellent CRM system >>> in Django, >>> I want Satchmo to use the shipping and contact information that >>> I've defined >>> in my CRM system, and if they both implemented IPerson, >>> IPostalAddress, and >>> IPhoneNumber, I could drop in those replacements. Without that, >>> I'm bound to >>> either duplicate my data across the two applications, hack Satchmo >>> to use my >>> CRM, or constrict my CRM system to require Satchmo. >> I can see abstract idea. But don't see right implementation idea. >> 1) You can do this all without all javaish interfaces. >> Python metamodel is open for changes when program is running. >> 2) Interfaces are not python way of doing stuff. google: duck typing. >> Please take my arguments into account and reconsider your idea with >> them. > > Except that interfaces in Trac's component system (and AFAIK also in > Zope or PyProtocols) aren't about typing *at all*; they're about > protocols for using, extending, or replacing functionality > (components). It might help to actually read up on stuff before > commenting. After writing this I realized that the example described by jag here was pretty misleading, in particular with respect to the interface names chosen (sorry jag ;), which definitely don't reflect correctly on how interfaces are used in "the Trac model". So I apologize if my reaction here was too harsh. But as the "we're pythonic, we use duck typing and documentation" meme has come up a couple times after that on this thread, let me repeat: that frankly has *nothing* to do with the component architecture as used in Trac that jag referred to originally. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Allow bypassing validation in newforms (#5153)
Hey all, I've created a ticket which has been closed as wontfix, and was told to bring it here. So here I am. <http://code.djangoproject.com/ticket/5153> So yeah, I want to be able to show previews of data that may at that point not be valid. Imagine there's a form with 12 required fields, and I want to enable users to see what their entry would look like even before they've completely filled everything in. (Using some AJAX tricks to do that without leaving the page.) For that kind of preview I want to reuse the templates that are used to present the final data. So I want to take the data from the form, pack it into a temporary/unsaved model object, and pass that object into the template. contrib.formtools.FormPreview implements a different kind of approach, and can't be used for this. Now, that use case may sound crazy to you (I don't know why it would, but hey). But the point is that there is currently NO WAY to do this with newforms. Honestly, the design of newforms.Form.clean(), where it deletes its own "cleaned_data" attribute as soon as there's a single validation error, is totally backwards and unpythonic. There should be *some* way to get at the cleaned_data values, even if some of the fields failed to validate. So, I created a fairly simple and clean patch to enable me to do what I want to do here: <http://code.djangoproject.com/attachment/ticket/5153/ ticket5153.diff> I personally think it'd be a good idea to apply. Thanks, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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: Allow bypassing validation in newforms (#5153)
Am 17.09.2007 um 04:17 schrieb Malcolm Tredinnick: > On Mon, 2007-09-17 at 00:23 +0200, Christopher Lenz wrote: >> Hey all, >> >> I've created a ticket which has been closed as wontfix, and was told >> to bring it here. So here I am. >> >><http://code.djangoproject.com/ticket/5153> > > I'm somewhere between -0 and -1 on this, for a couple of reasons. I > don't like the design and you can achieve the same functionality > without > any changes to core. Explanations below... > > [...] >> Now, that use case may sound crazy to you (I don't know why it would, >> but hey). But the point is that there is currently NO WAY to do this >> with newforms. Honestly, the design of newforms.Form.clean(), where >> it deletes its own "cleaned_data" attribute as soon as there's a >> single validation error, is totally backwards and unpythonic. There >> should be *some* way to get at the cleaned_data values, even if some >> of the fields failed to validate. > > If that was how the code worked, you would have a point. However, > Form.full_clean() fills cleaned_data with the normalised forms of any > fields that validated and puts any errors into the internal error > list. > So fields that are correct *do* appear in cleaned_data and it is not > erased when an error is encountered. Um, yes they are erased: <http://code.djangoproject.com/browser/django/trunk/django/ newforms/forms.py#L205> Am I missing something? > Reading your patch, it looks like you are actually going through > form_for_model or form_for_instance, since your real data flow changes > are in newforms/models.py. Since saving data into models absolutely > requires valid data, being able to disable data validation there would > be illogical. Saving data to the database should enforce valid data, simply populating a model instance from forms data doesn't really need to. It should by the default, sure. > I also don't like the change to disable validation in > Form.full_clean(), > because that makes it kind of a no-op: cleaning is all about > validation > and normalisation. Normalisation has to happen after or in parallel > with > validation, otherwise the normalisation code would have to be prepared > to handle every possible input format under the sun, instead of > just the > valid types. So once you disable validation, normalisation also > doesn't > occur and there's nothing for cleaning to do. We'd be adding an extra > code path in a few places that has be maintained and kept correct > in the > future and it's only purpose is to subvert the whole cleaning process. > Feels less neat than it should be to me. "Subvert the whole cleaning process"? No, the point is to be able to get the results from the cleaning process even when some validation fails. That may mean that cleaned_data is empty, or that fields are missing, etc. That doesn't matter, I can check form.is_valid() or form.errors to check whether the data is valid, I just want a way to still get at the data that's available so far! Seriously, this shouldn't require any of the workarounds you describe. Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
