On Wed, 2007-02-07 at 10:17 +0100, Michael Radziej wrote: > Malcolm Tredinnick: > > I just got back today from overseas, so after I've worked out which way > > is up I'll have a look at your fixes and fill in the missing bits > > (newforms + admin). > > Hey, nice to hear you're back and safe! > > It would certainly be good if you could look into the new patches, > there were a lot of conflicts.
After I sent the last mail, I realised the tests would probably not apply cleanly either (since I wrote the patch right before Russell rewrote the test infrastructure). > But there's no real need to hurry. newforms and admin are heading > for lots of changes, and unless Adrian would like to commit this > patch soon, you'd only have to go through a lot of merge conflicts. > > > Any documentation confusion would be good to hear about, since I > > remember that being a bit tricky to write the first time around -- > > finding the right mix between accurate, comprehensible and non-scary was > > the problem. > > I think a "when to use what" section about the differences between > escape, conditional_escape, the template filter `escape`, and > mark_for_escaping would be good. I needed this stuff mostly in > template filters and tags. Yeah, okay; I'll try to work that out. The trick is not to provide "too much information" in the wrong place. Somebody working just at the template level doesn't have to care about the auto-escaping mechanics (as you discovered when you only had to really worry about custom filters and tags)). Whereas somebody working at the lower level, like when writing template tags does need to know that. I'd tried to make some kind of summary in the "tag writers" section, but I'll give it another go. > And I had a surprise with escape(), since the template filter does > conditional_escape, but the one from django.utils.html does not (I > would have expected that it did conditional_escape, too). But I > didn't really had to use the docs much since I was very involved in > the discussion. So the "escape" template filter using conditional_escape was intentional for the reasons that were discussed on the list (basically, don't inadvertently double-escape and make it so that template authors can scatter "|escape" about with abandon for template fragments that might be used in both auto-escaping or non-auto-escaping contexts). I didn't change django.utils.html.escape() though, since I was trying to avoid breaking existing code and that function can be called from outside the templating system (in that sense, the naming is logical; away from the templating system, escape() escapes always). The way it's currently implemented, the auto-escaping additions are transparent and fully backwards-compatible. If we change django.utils.html.escape() that is no longer true, but we should make a decision about that before applying the patch to the mainline. > > > > Thanks for the testing. > > That's the least I can do! I am *very* interested in this patch. > > BTW, I saw that you're using git too (at least the patches look like > it), would it make sense to share the repositories? Yes, I'm using git (well, cogito and stg, really, but it's all the same storage on disk). I'll make my repo publically accessible shortly (when I fix up the patches) and you're quite welcome to pull from it if it will make testing easier. For Django core, I'm using "stacked git" (stg), since I want to be able to manage things as a stack of patches (rather than just one patch). I found I was often taking existing patches and modifying them slightly during testing and evaluation and I have a lot of active branches at any given time. I have it all down to a reasonably science now, but my dev setup is very Unix/Linux-based, since git doesn't really work well on Windows. But it's all "git" under the covers. I wrote up a brief description when I started using this a few months ago: http://www.pointy-stick.com/blog/topics/software/version%20control/ . 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
