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 [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 -~----------~----~----~----~------~----~------~--~---
