django.contrib.messages failing silently in safari when comma is used in message

If you try and send a message with new messaging app that contains a comma in the message it does not work in Safari. I'm not really sure why the json encoded message is not working in the Safari browser, but I fixed it by adding a base64 encode and decode step that encodes/decodes the message

Re: An idea to eliminate {% csrf token %}

Hi Wim, Your suggestion sounds something like Simon's SafeForm. While some elements of that proposal may end up in Django, it turns out that implementing SafeForm as the default solution requires *bigger* changes to existing code than adding the csrf_token, because you would need to pass

Re: An idea to eliminate {% csrf token %}

This was an excellent and well-put argument. As a newcomer to Django-developers, I was a bit confused by the {% csrf token %} inclusion (that breaks my code). Now, if I can just find some working code to use as a model ... -wolf On Dec 30, 2009 5:23 PM, "Wim Feijen" wrote:

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Right, sorry -- I'm gonna have to go with Eric on that, there are builtin libraries that do just that (from unicodedata import normalize). J. Leclanche / Adys On Thu, Dec 31, 2009 at 1:30 AM, James Bennett wrote: > On Wed, Dec 30, 2009 at 5:05 PM, Jerome Leclanche

Re: idea for using RequestContext by default

On Wed, 2009-12-30 at 14:28 -0800, Wim Feijen wrote: > Hello, > > In the discussions on CSRF there have been several proposals to > include RequestContext by default in render_to_response or in a > similar function. As a side note to my previous post, I'd like to > mention my favorite way to do

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 5:05 PM, Jerome Leclanche wrote: > When truncating characters, we are obviously talking about truncating just > that: characters. Truncating bytes is a behaviour implemented by |slice. You misunderstand: I'm not talking about bytes, I'm talking about

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 4:46 pm, James Bennett wrote: > 1. How many filters are we talking about here? At the very least it > seems like two: one for plain text and one for HTML (since you don't > want tags or character entities getting chopped off partway). Right now what's on the

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

> 1. How many filters are we talking about here? At the very least it > seems like two: one for plain text and one for HTML (since you don't > want tags or character entities getting chopped off partway). Why not have just truncate and truncate words, both with an argument to truncate html? > 2.

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 2:35 PM, Jerome Leclanche wrote: > This thread is 20 hours old, you've got a bunch of people who made clear > points on why the filter was needed/expected. You don't want to take lesson > off that? fine, as I said you can browse IRC logs, or even google

Admin-Actions also in the object details view

Hallo everyone, there is a very comfortable api for adding actions to the model admin in the admin site. These actions are then integrated into the admin's object list view of the given model type in the admin area. It seems to be also very logical to provide a way of showing these actions in

idea for using RequestContext by default

Hello, In the discussions on CSRF there have been several proposals to include RequestContext by default in render_to_response or in a similar function. As a side note to my previous post, I'd like to mention my favorite way to do this: render_to , see:

An idea to eliminate {% csrf token %}

Hello, For the past two days, I've been reading up on CSRF on the groups and on the excellent wiki by Luke Plant, and giving it a lot of thought. CRSF-protection should be on by default, that is clear. What I want to talk about is whether we can make the implementation a little bit less

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

What's this supposed to mean? If something is trivial to implement, it shouldn't be in the core? Tell me I'm reading it wrong, please, because I can think of 1000 reasons why this argument doesn't hold ground. J. Leclanche / Adys On Wed, Dec 30, 2009 at 11:39 PM, Alex Gaynor

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 3:36 PM, dannyr wrote: > > Alex, > > What's the rationale of including truncatewords into the core? How is > truncatewords different to truncate (characters)? > > On Dec 30, 12:29 pm, Alex Gaynor wrote: >> Ok, we get it, some

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Alex, What's the rationale of including truncatewords into the core? How is truncatewords different to truncate (characters)? On Dec 30, 12:29 pm, Alex Gaynor wrote: > Ok, we get it, some people want this feature.  I'd like to kindly > request that people just saying

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

flo...@gmail.com wrote: > I have a custom filter that does just this that I use in virtually > every single Django project I use. It's such a common pattern that it > seems almost silly not to have it included in core. It's also small > enough that it won't add much in the way of maintenance.

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 12:49 pm, Sean Brant wrote: > The last thing that needs to happen is bulling this into core. It's no > good for the community and that could be part of the perceived > perceptions problem. Just because enough people bitch does not mean > that its a good thing.

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Couldn't this problem actually be solved by actually just expanding the truncate_words syntax? instead of just allowing :"nr_of_words" to something like 'count[cw],ellipsis'. e.g. '10c,...' actually meaning cut after 10 characters instead of words, of course always rounded up or down for the last

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

The last thing that needs to happen is bulling this into core. It's no good for the community and that could be part of the perceived perceptions problem. Just because enough people bitch does not mean that its a good thing. With that said the reason behind the ticket being closed no longer seems

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On 12/30/09 3:29 PM, "Alex Gaynor" wrote: > Ok, we get it, some people want this feature. I'd like to kindly > request that people just saying "+1" stop. The number of people in > this thread is minuscule compared to the size of the django user > population, trying to

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 3:29 PM, Alex Gaynor wrote: > The video I linked earlier had a critical point that I think a lot of > people are missing, adding a single filter may not add a lot to the > developer's burden directly but it impacts the perceptions (and > realities)

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

PS; I don't see anybody "just saying +1". So far everyone has explained why they agree with inclusion, which is not the case of most of the (very few) comments against inclusion. J. Leclanche / Adys On Wed, Dec 30, 2009 at 10:29 PM, Alex Gaynor wrote: > Ok, we get it,

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 10:29 PM, Alex Gaynor wrote: > Ok, we get it, some people want this feature. I'd like to kindly > request that people just saying "+1" stop. The number of people in > this thread is minuscule compared to the size of the django user > population,

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

I think umovi makes a great point here when he mentions that templates are often used for things that are not HTML. "Be decoupled from HTML" is one of the core design philosophies listed in the docs. I'm not really advocating for or against adding a truncate filter, but I do think that "you

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Ok, we get it, some people want this feature. I'd like to kindly request that people just saying "+1" stop. The number of people in this thread is minuscule compared to the size of the django user population, trying to extrapolate from 1, 10, or even 100 people in this thread to a large

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

I'm +1 on adding a string truncation filter. I've yet to see a good reason not to, and there have been countless times I've needed it on real-world projects. As someone who has used the Django template language perhaps more extensively than anyone else out there, and as someone who has written

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Seems this thread is saying a few things: 1) It's already there with slice or using a CSS hack (eek!) 2) You should never truncate text on character boundaries anyways 3) Nobody is asking for it I'm new to Django and my first order of business was creating a truncate filter because I couldn't

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Just to add more confusion to this, how is truncation handled in other languages? Is it always and ellipse? What about Chinese, Japanese, Korean, and Arabic? I recently had to do some truncation stuff and switch from an ellipse to an image overlay with CSS that faded out the line at the end

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

I use templates sometimes to produce plain text, emails *without html*, etc, so CSS is not always a solution. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 7:06 am, Russell Keith-Magee wrote: > Secondly, IMHO raw truncation based on characters is bad practice for > human readable text. A sentence is composed of words, not characters. > Truncating a sentence mid-word isn't a typographical practice that I >

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 11:50 AM, David Zhou wrote: > Using CSS to truncate email addresses defeats the purpose of > truncating email addresses.  Not exactly "better", is it? That depends on whether your purpose is to make it fit in the space allotted, or to obfuscate the

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 1:37 PM, Ian Kelly wrote: > All of which could be handled just as well or better using CSS, unless > there's something I'm missing, which is the reason I asked. Using CSS to truncate email addresses defeats the purpose of truncating email

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

The css tricks you linked are shady towards cross-browser compliance. Using XUL on a website just to have it working in firefox? No, thank you. What about serving plain text or actually any kind of non-html content? Why would I use CSS there? How far are you going to go just to prove that every

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 11:21 AM, Jerome Leclanche wrote: > > On Wed, Dec 30, 2009 at 8:02 PM, Ian Kelly wrote: >> >> What I haven't seen yet for this filter is a clear use case.  If >> you're just trying to get something working quickly, then slice is

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 8:02 PM, Ian Kelly wrote: > > What I haven't seen yet for this filter is a clear use case. If > you're just trying to get something working quickly, then slice is > fine. When you're ready to go back and do it right, then the optimal > solution is

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 10:25 AM, Nic Pottier wrote: > On Dec 30, 8:55 am, Alex Gaynor wrote: >> I'd highly recommend watchinghttp://www.youtube.com/watch?v=tscMnoS4YU8in it >> this *exact* question >> comes up and Russ, Malcolm, and a few other

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 8:55 am, Alex Gaynor wrote: > I'd highly recommend watchinghttp://www.youtube.com/watch?v=tscMnoS4YU8in it > this *exact* question > comes up and Russ, Malcolm, and a few other people discuss the pros > and cons of adding new template tags/filters. > > Alex

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 10:53 AM, Nic Pottier wrote: > On Dec 29, 10:01 pm, Alex Gaynor wrote: >> Adding the ellepsis is as simple as: >> >> {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %} >> >> Given that the recent expansion of the {%

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 2:06 PM, Russell Keith-Magee wrote: > Secondly, IMHO raw truncation based on characters is bad practice for > human readable text. A sentence is composed of words, not characters. > Truncating a sentence mid-word isn't a typographical practice

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 29, 10:01 pm, Alex Gaynor wrote: > Adding the ellepsis is as simple as: > > {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %} > > Given that the recent expansion of the {% if %} tag makes that so easy > I don't think it's a compelling reason to add a {%

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Dec 30, 2009, at 6:06 AM, Russell Keith-Magee wrote: > Firstly, as James points out, slice already exists, and the ellipsis > difference between slice and truncate can be easily overcome with > additional code. In the past I have had the need for a filter that works not just on the end of

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Dec 30, 2009 at 08:06:02PM +0800, Russell Keith-Magee wrote: > On Wed, Dec 30, 2009 at 8:15 AM, Nic Pottier wrote: > > > > New to Django, but certainly not web development.  After being > > pleasantly surprised with a

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

There is a truncate filter, it's called 'slice': http://docs.djangoproject.com/en/1.1/ref/templates/builtins/#slice To show the first 10 chars do: {{ mystring|silce:":10" }} There's also truncatewords to make sure you always get whole words:

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

On Wed, Dec 30, 2009 at 8:15 AM, Nic Pottier wrote: > > New to Django, but certainly not web development.  After being > pleasantly surprised with a lot of the available Django filters I was > rather surprised not to see a string truncation filter included. > > A little

Re: Ticket #5025 - truncate filter, why hasn't it been accepted?

Alex Gaynor wrote: > Adding the ellepsis is as simple as: > > {{ foo|slice:":100" }}{% if foo|length > 100 %}...{% endif %} Come on Alex, in what universe it qualifies as "simple"?! -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post