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

2009-12-30 Thread Sean Brant
I created a ticket for this http://code.djangoproject.com/ticket/12470
in case someone wants it.

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Sean Brant
Sorry should note, this happens when using the CookieStorage backend.

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Sean Brant
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 string.

def _encode(self, messages, encode_empty=False):
...
if messages or encode_empty:
for message in messages:
message.message = base64.b64encode(message.message)
encoder = MessageEncoder(separators=(',', ':'))
...

def _decode(self, data):
...
messages = json.loads(value, cls=MessageDecoder)
for message in messages:
message.message = base64.b64decode
(message.message)
return messages
except ValueError:
pass
 ...

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Luke Plant
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 additional info from the request to Form for it to be 
able to do the CSRF checks.  It also only works if you are using 
Django Forms and rendering them via {{ form }} (instead of field-by-
field, for instance).

If you want to see how we got to where we are, have a look at this 
thread: http://groups.google.com/group/django-
developers/browse_thread/thread/3d2dc750082103dc/f3beb18c27fb7152

(OK, that was a nasty trick - the thread is huge, we discussed this 
nearly to death, but that's why I'm not going to repeat all the 
arguments here).

Also, you can use CsrfResponseMiddleware as an interim measure to stop 
your code from breaking, so the change to require csrf_token isn't 
quite so bad.

Thanks,

Luke

-- 
"It is a truth universally acknowledged, that a single man in 
possession of a good fortune, must be in want of a wife." (Jane 
Austen)

Luke Plant || http://lukeplant.me.uk/

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Wolf Halton
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:

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 intrusive.

At the moment, (and please correct me if I am wrong), every form
template needs a {% csrf_token %} and RequestContext passed to it. As
I understand it, forms from existing, not yet upgraded applications
stop functioning. And every new form template written needs to include
the same extra variable {% csrf_token %} in the template.

Personally, I'd like to find a solution which requires less work by
the programmer and by default, handles all common cases, while any
rare cases still require conscious effort of the programmer. I really
recommend reading "Less is more", by 37 signals. My proposal for such
a solution is:

1. CSRF protection should be on by default.
2. Rendering {{ form }} should include the token by default.
3. When rendering a form "by hand", the token should be inserted by
the programmer. This works like rendering a formset; and I don't find
it beautiful, but workable.

Benefits are:
1. Old code works.
2. Writing a new template stays as simple as it is.

Drawbacks:
1. Public forms shouldn't be protected. In my views, when I render a
non-public form it is always preceded by either a login_required or a
permission_required decorator and I was thinking in the line of using
that as a trigger.
2. Forms which post to other sites should not leak the token.
Therefore, each Form should definitely have a optional argument
(enable_csfr = False). So the default is protect and the programmer
doesn't need to do anything about it, and there is an option to
disable the token on the form level. So, what happens if a programmer
forgets to disable the token? The form will leak the token. Now I'd
like to make some assumptions and these are:
a) most Django forms post to their own site.
b) when I post to a foreign site, I apparently trust the site and am
looking forward to cooperate with it. I consider it higly unlikely
that this site will intercept my token and use it for ill.
So in the case the programmer makes a mistake and forgets to disable
the token, it still is unlikely he endangers his site.

I really hope this may inspire you and help in implementing a less
intrusive way of CSRF-safe forms. As you, I am looking for a solution
which benefits us most and at the same time, has the least drawbacks.
Please correct me if I am wrong and take this message in the spirit it
is meant, that is: to describe an idea.

Best regards,

Wim Feijen

--

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 unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Jerome Leclanche
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 
> 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
> composed and decomposed characters.
>
> For example, 'ü' can be represented as either:
>
> 1. 00fc  (LATIN SMALL LETTER U WITH DIARESIS), or
>
> 2. 0075 (LATIN SMALL LETTER U) *followed by* 0308 (COMBINING DIARESIS)
>
> Option 1 is composed, option 2 is decomposed and is actually *two
> Unicode characters*, not "two bytes", and so character-based slicing
> will chop off the combining diaresis. The only way to avoid this is to
> have the filter do Unicode normalization to composed characters (e.g.,
> normalization form NFC or NFKC).
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
>
> 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 unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




Re: idea for using RequestContext by default

2009-12-30 Thread Will LaShell
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 this: render_to , see:

The  generic view function  direct_to_template already handles this
need.  If anything we could add a line in the documentation or tutorials
pointing this usage out.

> http://www.djangosnippets.org/snippets/821/
> 
> Best regards,
> 
> Wim Feijen

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread James Bennett
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
composed and decomposed characters.

For example, 'ü' can be represented as either:

1. 00fc  (LATIN SMALL LETTER U WITH DIARESIS), or

2. 0075 (LATIN SMALL LETTER U) *followed by* 0308 (COMBINING DIARESIS)

Option 1 is composed, option 2 is decomposed and is actually *two
Unicode characters*, not "two bytes", and so character-based slicing
will chop off the combining diaresis. The only way to avoid this is to
have the filter do Unicode normalization to composed characters (e.g.,
normalization form NFC or NFKC).


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread flo...@gmail.com
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 table with #5025 is a single filter: truncate.

> 2. How does this interact with internationalization? Not every
> language or locale uses an ellipsis for this (and, really, this needs
> to be solved regardless so the existing truncate_words can play nice
> with non-English use cases).

I agree that this is a separate issue that needs to be solved for
truncatewords.

> 3. Similarly to the above two, how does this interact with languages
> which commonly use composed characters in Unicode? Cutting a character
> in half (and thus presenting output that's completely wrong) probably
> isn't expected behavior, so how would such a filter deal with this?
> Would it need to do Unicode normalization as well?

Good catch!  Quite an edge case, but luckily it turns out the
unicodedata module from the standard library can do all of the
normalization for us.

> 3. Is adding more filters really the way to do this? Could existing
> filters have their functionality expanded instead?

I think the filter in the patch is the clearest way of expressing this
idea.  That being said, I'm sure proposals to other filters would be
met with consideration.

> These types of questions have to have answers before I'll even think
> about supporting a change, but so far I don't really see anyone
> proposing answers -- just an endless litany of "me too"-type comments
> which don't add anything useful to the discussion.

It's no use discussing these details if the core committers and
influential contributors are against the idea of a truncate filter in
general.

I'd like to propose that we have BDFL rule on this issue.  It seems
that most if not all of the arguments have been put on the table.  If
the decision is yes, let's include some kind of truncate tag, then we
can continue on these discussions about the finer details.  If the
decision is not to include a truncate tag, then we won't have wasted
any time arguing about a moot point.

Thanks,
Eric Florenzano

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Jerome Leclanche
> 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. How does this interact with internationalization? Not every
> language or locale uses an ellipsis for this (and, really, this needs
> to be solved regardless so the existing truncate_words can play nice
> with non-English use cases).

This is an issue for truncate_words too, which is solved by adding an
argument ellipsis="...".

> 3. Similarly to the above two, how does this interact with languages
> which commonly use composed characters in Unicode? Cutting a character
> in half (and thus presenting output that's completely wrong) probably
> isn't expected behavior, so how would such a filter deal with this?
> Would it need to do Unicode normalization as well?

When truncating characters, we are obviously talking about truncating just
that: characters. Truncating bytes is a behaviour implemented by |slice.

> 3. Is adding more filters really the way to do this? Could existing
> filters have their functionality expanded instead?

That's.. Well, if we go with what I described in my first answer, we will
still only have two filters, but with additional behaviour. Truncating
characters with truncate_words wouldn't make any sort of sense, so I'm
positive if we do add a character truncating feature, it will require a new
filter. As I also said a while ago, users just expect it to be called
"truncate".

If you have further questions/opinions (this goes for everyone against
adding such a filter), voice them just like this and they will get an
answer. Asking for people to "stop saying +1" just makes you look like you
don't want people disagreeing with you.


J. Leclanche / Adys


On Thu, Dec 31, 2009 at 12:46 AM, James Bennett wrote:

> 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
> > results[1]. I don't see anywhere any kind of mention of the "slice"
> filter
> > which, so far, has been the only working replacement proposed.
> > [1]
> http://www.google.com/search?sourceid=chrome=UTF-8=django+truncate+filter
>
> And yet there's also been some legitimate pushback, and no real
> response to actual design problems raised by the proposal. Instead of
> the litany of "+1, everybody needs this and it's so trivial, why won't
> you listen to us", how about giving good answers to the following
> questions:
>
> 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).
>
> 2. How does this interact with internationalization? Not every
> language or locale uses an ellipsis for this (and, really, this needs
> to be solved regardless so the existing truncate_words can play nice
> with non-English use cases).
>
> 3. Similarly to the above two, how does this interact with languages
> which commonly use composed characters in Unicode? Cutting a character
> in half (and thus presenting output that's completely wrong) probably
> isn't expected behavior, so how would such a filter deal with this?
> Would it need to do Unicode normalization as well?
>
> 3. Is adding more filters really the way to do this? Could existing
> filters have their functionality expanded instead?
>
> These types of questions have to have answers before I'll even think
> about supporting a change, but so far I don't really see anyone
> proposing answers -- just an endless litany of "me too"-type comments
> which don't add anything useful to the discussion.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> --
>
> 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 unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread James Bennett
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
> results[1]. I don't see anywhere any kind of mention of the "slice" filter
> which, so far, has been the only working replacement proposed.
> [1] http://www.google.com/search?sourceid=chrome=UTF-8=django+truncate+filter

And yet there's also been some legitimate pushback, and no real
response to actual design problems raised by the proposal. Instead of
the litany of "+1, everybody needs this and it's so trivial, why won't
you listen to us", how about giving good answers to the following
questions:

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).

2. How does this interact with internationalization? Not every
language or locale uses an ellipsis for this (and, really, this needs
to be solved regardless so the existing truncate_words can play nice
with non-English use cases).

3. Similarly to the above two, how does this interact with languages
which commonly use composed characters in Unicode? Cutting a character
in half (and thus presenting output that's completely wrong) probably
isn't expected behavior, so how would such a filter deal with this?
Would it need to do Unicode normalization as well?

3. Is adding more filters really the way to do this? Could existing
filters have their functionality expanded instead?

These types of questions have to have answers before I'll even think
about supporting a change, but so far I don't really see anyone
proposing answers -- just an endless litany of "me too"-type comments
which don't add anything useful to the discussion.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




Admin-Actions also in the object details view

2009-12-30 Thread Roman Glebov
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 the object detail view.

This would be also very comfortable because it would not require a
django developer to override the object detail view template.
And would make django development more object oriented: it would require
to define all specific actions in the admin model.

I will try to develop the required functionality.

With best wishes
Roman Glebov

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




idea for using RequestContext by default

2009-12-30 Thread Wim Feijen
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:

http://www.djangosnippets.org/snippets/821/

Best regards,

Wim Feijen

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




An idea to eliminate {% csrf token %}

2009-12-30 Thread Wim Feijen
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 intrusive.

At the moment, (and please correct me if I am wrong), every form
template needs a {% csrf_token %} and RequestContext passed to it. As
I understand it, forms from existing, not yet upgraded applications
stop functioning. And every new form template written needs to include
the same extra variable {% csrf_token %} in the template.

Personally, I'd like to find a solution which requires less work by
the programmer and by default, handles all common cases, while any
rare cases still require conscious effort of the programmer. I really
recommend reading "Less is more", by 37 signals. My proposal for such
a solution is:

1. CSRF protection should be on by default.
2. Rendering {{ form }} should include the token by default.
3. When rendering a form "by hand", the token should be inserted by
the programmer. This works like rendering a formset; and I don't find
it beautiful, but workable.

Benefits are:
1. Old code works.
2. Writing a new template stays as simple as it is.

Drawbacks:
1. Public forms shouldn't be protected. In my views, when I render a
non-public form it is always preceded by either a login_required or a
permission_required decorator and I was thinking in the line of using
that as a trigger.
2. Forms which post to other sites should not leak the token.
Therefore, each Form should definitely have a optional argument
(enable_csfr = False). So the default is protect and the programmer
doesn't need to do anything about it, and there is an option to
disable the token on the form level. So, what happens if a programmer
forgets to disable the token? The form will leak the token. Now I'd
like to make some assumptions and these are:
a) most Django forms post to their own site.
b) when I post to a foreign site, I apparently trust the site and am
looking forward to cooperate with it. I consider it higly unlikely
that this site will intercept my token and use it for ill.
So in the case the programmer makes a mistake and forgets to disable
the token, it still is unlikely he endangers his site.

I really hope this may inspire you and help in implementing a less
intrusive way of CSRF-safe forms. As you, I am looking for a solution
which benefits us most and at the same time, has the least drawbacks.
Please correct me if I am wrong and take this message in the spirit it
is meant, that is: to describe an idea.

Best regards,

Wim Feijen

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Jerome Leclanche
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  wrote:

> 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 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 percentage of the community wants this is
> >> simply not possible.
> >>
> >> 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) of what kinds of things are reasonable for inclusion in
> >> core.  The simple fact is some people want this, and some don't.  Not
> >> having this is not an intractable problem for people who need it, in
> >> fact it's a trivial one.
> >>
> >> I don't really care whether this is included or not, but it seems to
> >> me that there's very little in terms of new ground in the discussion.
> >>
> >> Alex
> >>
> >> --
> >> "I disapprove of what you say, but I will defend to the death your
> >> right to say it." -- Voltaire
> >> "The people's good is the highest law." -- Cicero
> >> "Code can always be simpler than you think, but never as simple as you
> >> want" -- Me
> >
> > --
> >
> > 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 unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> >
> >
> >
>
> Probably that truncate_words is *slightly* less trivial to implement.
> Plus it's been there since forever, removing it would be an extremely
> large backwards compatible change.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
>
> --
>
> 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 unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Alex Gaynor
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 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 percentage of the community wants this is
>> simply not possible.
>>
>> 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) of what kinds of things are reasonable for inclusion in
>> core.  The simple fact is some people want this, and some don't.  Not
>> having this is not an intractable problem for people who need it, in
>> fact it's a trivial one.
>>
>> I don't really care whether this is included or not, but it seems to
>> me that there's very little in terms of new ground in the discussion.
>>
>> Alex
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your
>> right to say it." -- Voltaire
>> "The people's good is the highest law." -- Cicero
>> "Code can always be simpler than you think, but never as simple as you
>> want" -- Me
>
> --
>
> 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 unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

Probably that truncate_words is *slightly* less trivial to implement.
Plus it's been there since forever, removing it would be an extremely
large backwards compatible change.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread dannyr

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 "+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 percentage of the community wants this is
> simply not possible.
>
> 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) of what kinds of things are reasonable for inclusion in
> core.  The simple fact is some people want this, and some don't.  Not
> having this is not an intractable problem for people who need it, in
> fact it's a trivial one.
>
> I don't really care whether this is included or not, but it seems to
> me that there's very little in terms of new ground in the discussion.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Bas van Oostveen
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.  Also, there
> already exists a truncate_words, which has nice symmetry with the
> proposed name.  Finally, as has been said before, it's something that
> new users intuitively expect to find, so let's not disappoint them.
>
> I quite strongly feel that slice is not a suitable alternative,
> because 1) adding the ellipses requires a non-trivial amount of
> additional template logic (and this logic need be repeated every time
> ellipses are wanted) and 2) it makes the actual markup of the template
> less semantically relevant.
>
> Count me as a big +1 for including this.
>
> Thanks,
> Eric Florenzano
>
>   

Agree +1 on including it into Django.
(both truncate and truncate_html)

I'm having similar experiences as Eric, think 7 out of 10 sites
eventually use it in one way or another. To give some quick
examples; filenames, links, fullnames with hover, limiting user
generated content, csv exports, etc.

Sometimes in conjunction with truncate_words, like:

{{ content|truncate_words:40|truncate_letters:200 }

To make sure that text (mostly from user content, or scrapers)
get's limited to some fair amount even one words are extremely
long.

We also include it in django-extensions as truncate_letters.

It always seemed strange why truncate_words is included and
something to truncate letters isn't. Seems a logical pair

I also feel slice isn't an alternative, if it where then by the same
token we could remove truncate_words because you could also
split and slice. And it means repeating yourself many times over
when it can be solved with a simple template_tag.

Regards,
Bas

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Nic Pottier
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. With that said the reason behind the ticket
> being closed no longer seems valid.
>
> A template filter for shortening a string seems like a logical
> addition to truncatewords. At the very least reassessing the ticket
> status might be a good start.

I'll make this my last reply.. promise. :)

But how is this bullying?

I mean, there was a clean patch submitted, complete with unit tests,
years ago.  There is clearly demand, and has been for at least a few
years.

If anything, the bullying seems to be against the 'users' by the
'devs' rather than the other way around.  It all seems like a bit of a
mountain out of a mole hill.  It is one tiny filter, with clear demand
and no side effects to other parts of the system.  I couldn't think of
a lower risk patch.

I guess my question is, what in the world is the minus?  You satisfy a
demonstrated need for a very low effort and with no side effects.

As a last little quip, I have to say I do understand the resistance to
change, and also fully understand how one becomes a bit entrenched in
a way of doing things after working on a product for many years.  But
at the same time, you really have to appreciate what users, especially
NEW users say about their experience.  It is near impossible to get
into that mindset again after you have used a system for a while.
Yes, truncate is something that is easily worked around, but it is
also something that lots of new users to Django seem to miss, and it
is a shame to make them all reinvent that wheel again and again.

That is all from me. ;)

-Nic

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Killian De Smedt
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 word so we don't end in the middle, and finally having a 3-dot
ellipsis. This can be done perfectly backwards-compatible as far as I know
and doesn't flood the namespace with dozens of filters with similar
functionality. Adding truncate now would mean a 3th filter that does more or
less the same (and then I even don't count slice), which in my opinion is
only even more confusing.

I'm also no big fan of putting this logic into templates anyway, I think too
many people use views just as a passthrough for object managers and do the
real data transform for viewing in the template, which isn't the purpose of
a template language. In general I am even against many of the already
included filters, so for me adding a new filter is certainly vote -1.

2009/12/30 Sean Brant 

> 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 valid.
>
> A template filter for shortening a string seems like a logical
> addition to truncatewords. At the very least reassessing the ticket
> status might be a good start.
>
> --
>
> 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 unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Sean Brant
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 valid.

A template filter for shortening a string seems like a logical
addition to truncatewords. At the very least reassessing the ticket
status might be a good start.

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Peter Landry
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 extrapolate from 1, 10, or even 100 people in
> this thread to a large percentage of the community wants this is
> simply not possible.
> 
> 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) of what kinds of things are reasonable for inclusion in
> core.  The simple fact is some people want this, and some don't.  Not
> having this is not an intractable problem for people who need it, in
> fact it's a trivial one.
> 
> I don't really care whether this is included or not, but it seems to
> me that there's very little in terms of new ground in the discussion.
> 
> Alex

Sorry if this takes things too far off-topic, but what is the proper way to
express support for a feature/ticket then? If the original argument is "not
enough people want it", I think it's fair that people voice their support,
and most have included specific use cases. What is the alternative?

Peter

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread David Zhou
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) of what kinds of things are reasonable for inclusion in
> core.

No one's ignoring that.  But the truncate filter, specifically, isn't
breaking new ground in terms of included filters. There's *already* a
truncatewords filter.  Adding this will not meaningfully impact the
perceptions of core.

-- dz

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Jerome Leclanche
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, 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 percentage of the community wants this is
> simply not possible.
>
> 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) of what kinds of things are reasonable for inclusion in
> core.  The simple fact is some people want this, and some don't.  Not
> having this is not an intractable problem for people who need it, in
> fact it's a trivial one.
>
> I don't really care whether this is included or not, but it seems to
> me that there's very little in terms of new ground in the discussion.
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me
>
> --
>
> 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 unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Jerome Leclanche
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, trying to extrapolate from 1, 10, or even 100 people in
> this thread to a large percentage of the community wants this is
> simply not possible.
>

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
results[1]. I don't see anywhere any kind of mention of the "slice" filter
which, so far, has been the only working replacement proposed.

[1]
http://www.google.com/search?sourceid=chrome=UTF-8=django+truncate+filter

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Taylor Marshall
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 should be using CSS instead" is an invalid argument against
it.

On Wed, Dec 30, 2009 at 2:33 PM, umovi  wrote:
> 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 unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
.
> For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Alex Gaynor
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 percentage of the community wants this is
simply not possible.

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) of what kinds of things are reasonable for inclusion in
core.  The simple fact is some people want this, and some don't.  Not
having this is not an intractable problem for people who need it, in
fact it's a trivial one.

I don't really care whether this is included or not, but it seems to
me that there's very little in terms of new ground in the discussion.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread j...@jeffcroft.com
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 books on CSS and web
standards, I can confirm without a doubt that string truncation is
needed in the real world, and that accomplishing it using slice and
adding the ellipsis using template code, as Alex Gaynor suggested, is
both ugly and not DRY at all.

So...why not?

On Dec 30, 11:15 am, John Debs  wrote:
> 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
> > particularly want to encourage.
>
> I think the question that needs to be asked now is: What would it take
> to convince the core members that this belongs in core?
>
> There are obviously a *lot* of django developers that want this, best
> practice or not, and web development is often about making trade-offs
> that work best for your scenario. Two of Django's core philosophies
> (correct me if I'm wrong...) are making common developer tasks easy,
> and keeping things DRY, and the current state of string truncation in
> Django is neither of those things.
>
> I've seen a few +1's but no -1's, despite some resistance. Can we get
> the opinions of a few more core developers so that this has a chance
> of slipping in before the Jan. 5 feature deadline?

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Eric
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 find one.  I also found it pretty
odd that it wasn't supported out of the box.  I don't think slice is
the same thing since ellipses are important in this case and adding
conditionals in templates to accomplish this is cumbersome and sloppy.

I also feel the argument that there is no reasonable scenario for
wanting to truncate text on character boundaries is pretty arrogant.
I've found many situations where this is desirable -- like the long
file paths mentioned earlier.

I joined this group, just so I can ask for it to be added to core.  It
doesn't look like I'm alone.

I don't understand the argument for not including it.  It's pretty
obviously wanted and it's not going to turn journalism on it's ear.
It would appear there is also very little cost to including it.

Eric

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread varikin
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 because of the translation issues of truncating.

I really don't think this is worthwhile because it is easy to write
truncation to meet your requirements. One person wants word
boundaries, another wants ellipse in the center for long names.
Someone else might not want any ellipse, but not now to just use slice
instead. I see truncation as a design decision. Can true filter be
added such that it works for 80% of the use cases while being easy to
use?

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread umovi
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread John Debs
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
> particularly want to encourage.

I think the question that needs to be asked now is: What would it take
to convince the core members that this belongs in core?

There are obviously a *lot* of django developers that want this, best
practice or not, and web development is often about making trade-offs
that work best for your scenario. Two of Django's core philosophies
(correct me if I'm wrong...) are making common developer tasks easy,
and keeping things DRY, and the current state of string truncation in
Django is neither of those things.

I've seen a few +1's but no -1's, despite some resistance. Can we get
the opinions of a few more core developers so that this has a chance
of slipping in before the Jan. 5 feature deadline?

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Ian Kelly
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 address.  I had understood it to be the
former.  For the latter, using truncate isn't a good solution either.
What if the address happens to be shorter than the truncated length?

Ian

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread David Zhou
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 addresses.  Not exactly "better", is it?

CSS is not a universal panacea.

-- dz

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Jerome Leclanche
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 single person who has
ever asked for a "truncate filter" is wrong? because there's a hell of a lot
of them.

J. Leclanche / Adys


On Wed, Dec 30, 2009 at 8:37 PM, Ian Kelly  wrote:

> 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
> >> fine.  When you're ready to go back and do it right, then the optimal
> >> solution is to use CSS [1].  If you only want to truncate at word
> >> boundaries, then you'll just use truncate_words.  What requirement
> >> does a truncate filter satisfy that these other solutions don't?
> >>
> >> [1] http://mattsnider.com/css/css-string-truncation-with-ellipsis/
> >>
> >> Ian
> >
> > Then perhaps you should read the past few mails, I've given 5 different
> use
> > cases.
> > J. Leclanche / Adys
>
> 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.
>
> Ian
>
> --
>
> 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 unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Ian Kelly
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
>> fine.  When you're ready to go back and do it right, then the optimal
>> solution is to use CSS [1].  If you only want to truncate at word
>> boundaries, then you'll just use truncate_words.  What requirement
>> does a truncate filter satisfy that these other solutions don't?
>>
>> [1] http://mattsnider.com/css/css-string-truncation-with-ellipsis/
>>
>> Ian
>
> Then perhaps you should read the past few mails, I've given 5 different use
> cases.
> J. Leclanche / Adys

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.

Ian

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Jerome Leclanche
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 to use CSS [1].  If you only want to truncate at word
> boundaries, then you'll just use truncate_words.  What requirement
> does a truncate filter satisfy that these other solutions don't?
>
> [1] http://mattsnider.com/css/css-string-truncation-with-ellipsis/
>
> Ian


Then perhaps you should read the past few mails, I've given 5 different use
cases.

J. Leclanche / Adys

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Ian Kelly
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 people discuss the pros
>> and cons of adding new template tags/filters.
>>
>> Alex
>
> Thanks, that's a useful link.  The relevant portion starts at ~15:00
> for those that are interested.
>
> But really, the sum total of that discussion with regards to truncate
> seemed to be:
>  1) truncate doesn't exist because it wasn't useful in Journalism
>  2) you can add it yourself
>  3) we cover 80/20
>
> What it explicitly doesn't say is that there is a huge cost to having
> a new filter in core.
>
> Don't get me wrong, I absolutely agree on the 80/20 principle, and on
> that a clean and simple interface is hugely valuable. (The PHP mess is
> a clear counterpoint here)
>
> But I disagree that truncate is somehow an esoteric filter.  RoR has
> it, Smarty has it, as do countless others, it just isn't that
> unusual.

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 to use CSS [1].  If you only want to truncate at word
boundaries, then you'll just use truncate_words.  What requirement
does a truncate filter satisfy that these other solutions don't?

[1] http://mattsnider.com/css/css-string-truncation-with-ellipsis/

Ian

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Nic Pottier
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

Thanks, that's a useful link.  The relevant portion starts at ~15:00
for those that are interested.

But really, the sum total of that discussion with regards to truncate
seemed to be:
  1) truncate doesn't exist because it wasn't useful in Journalism
  2) you can add it yourself
  3) we cover 80/20

What it explicitly doesn't say is that there is a huge cost to having
a new filter in core.

Don't get me wrong, I absolutely agree on the 80/20 principle, and on
that a clean and simple interface is hugely valuable. (The PHP mess is
a clear counterpoint here)

But I disagree that truncate is somehow an esoteric filter.  RoR has
it, Smarty has it, as do countless others, it just isn't that
unusual.

-Nic

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Alex Gaynor
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 {% if %} tag makes that so easy
>> I don't think it's a compelling reason to add a {% truncate %} tag.
>>
>> Alex
>
> Thank you for acknowledging that slice is not at all the same thing as
> a real truncate.  Having that kind of {% if %} scattered around your
> templates is exactly the reason we need a filter.
>
> Perhaps the use case just hasn't been explained enough.
> truncate_words is not the same thing, and should indeed be used if you
> are truncating a paragraph of text.  truncate comes in when you have a
> URL or filename, which won't have any spaces and you don't want to
> blow off the end of your div or ruin your table cells.
>
> I guess I don't understand the big drawback?  There is obviously a
> need, some quick googling finds quite a few independent
> implementations of this filter for Django, plus we have a few patches
> submitted, some IRC logs, and the people who've piped up on this list.
>
> Is there a big overhead I'm not seeing in adding this filter, either
> in performance or maintenance?  It certainly seems like a lot of users
> want it, and as others have said, it probably would garner more usage
> than some of the other stranger filters present in core.
>
> -Nic
>
> PS. I agree that smarty's truncate seems like a pretty reasonable spec
> if we really want to do it right:
> 
>
> I'd be perfectly willing to write up a patch to that spec against the
> current code base if I knew it wouldn't languish.
>
> --
>
> 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 unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>
>

I'd highly recommend watching
http://www.youtube.com/watch?v=tscMnoS4YU8 in 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

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Jerome Leclanche
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 that I
> particularly want to encourage.


Please...
Please, please, please, do NEVER assume the use cases on your own websites
are the only ones other users will ever need.

Are you going to truncatewords on long filenames?
What about on hashes? On Email addresses?
Here is where I use truncate:
http://db.mmo-champion.com/i/35191/schematic-wonderheal-xt68-shades/ -
bottom of the right box. I can't truncate such small names based on words
alone.


> As for why this patch has languished for so long - one major reason is
> that nobody has made an issue of it previously. By my count, this
> thread is only the third time that someone has made the case for a
> built-in truncate filter

Oh NO you don't. PLEASE. grep your irc logs for truncate+filter, I know
you've been on irc long enough.


J. Leclanche / Adys

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Nic Pottier
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 {% truncate %} tag.
>
> Alex

Thank you for acknowledging that slice is not at all the same thing as
a real truncate.  Having that kind of {% if %} scattered around your
templates is exactly the reason we need a filter.

Perhaps the use case just hasn't been explained enough.
truncate_words is not the same thing, and should indeed be used if you
are truncating a paragraph of text.  truncate comes in when you have a
URL or filename, which won't have any spaces and you don't want to
blow off the end of your div or ruin your table cells.

I guess I don't understand the big drawback?  There is obviously a
need, some quick googling finds quite a few independent
implementations of this filter for Django, plus we have a few patches
submitted, some IRC logs, and the people who've piped up on this list.

Is there a big overhead I'm not seeing in adding this filter, either
in performance or maintenance?  It certainly seems like a lot of users
want it, and as others have said, it probably would garner more usage
than some of the other stranger filters present in core.

-Nic

PS. I agree that smarty's truncate seems like a pretty reasonable spec
if we really want to do it right:


I'd be perfectly willing to write up a patch to that spec against the
current code base if I knew it wouldn't languish.

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Sean Brant

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 
the string but sometimes in the middle. For example truncating a long filename, 
you might want to show the first bit and the last it.

myfilewithasuperlong...thisnameisreallylong.jpg

Doing this in the template is not a good idea, but with a template filter you 
can do it with an extra argument.

+1

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Arthur Furlan
-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 lot of the available Django filters I was
> > rather surprised not to see a string truncation filter included.
> >
> > A little googling shows I'm not the only one, there are tons of people
> > writing their own filters to accomplish this, and sure enough a nice
> > looking patch submitted two (TWO!) years ago to add a |truncate.
> >
> > I'd be curious to hear what the reason for not accepting this patch
> > is.  String truncation is a pretty common task, and having it built in
> > seems like a no-brainer.
> 
> I disagree.
> 
> Firstly, as James points out, slice already exists, and the ellipsis
> difference between slice and truncate can be easily overcome with
> additional code.
> 
> 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
> particularly want to encourage.
> 
> I would be marginally more inclined to support a truncate filter that
> obeyed word boundaries  i.e., no more than 50 characters, but stop at
> the end of the last complete word. However, even with this
> modification - what's the use case for an N character truncation? It
> can't (or shouldn't be) to make sure that text will fit into a visual
> space. You can't guarantee how wide N characters will be at
> render-time due to differences in character width. If you want to
> truncate for display purposes, you should be looking at CSS overflow
> properties or other display-level tricks.

This feature, of truncating in word bondaries or truncating
based on characters, could be added as an option. I think it's valid
to take a look at the truncate[1] filter of the Smarty Template Engine
because it solves some of the problems that have been discussed here.

[1]. http://www.smarty.net/manual/en/language.modifier.truncate.php


- -- 
Best regards,

Arthur Furlan (afurlan)
afur...@afurlan.org
http://blog.afurlan.org
Public GPG KeyID: 27D81084

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJLO0fKAAoJEOW5JtQn2BCENIMP/0ex/IKnSFlwHwQTiclfnRyK
ooXODJXsk90sh8GaocLBic3NJ+pminMKHclavZKdlXYgA9RSMTlfLXRJU7WFvEJx
hZ5U2eDUGXyMy++Onj04fAJG8Q7+4mRRlgkEH520b2RRPndyBw4RMpbIaTYzi+Pc
FA1hgTmK+j3ojbkRZeQIYn3w53n0R4n990YumrfclcpOtWc7/YW0g0+uEBdLJ4pZ
B8uAFlDZCABcfj6wS6kewJfXRxDzX+6ch5cMgTle1LfRlWOyu+RAeV5An8fxykw9
pGZClIVHrE5zeFus8J7RawnodbaiuxfTgEGnWqLii/ddrjBEMebeKOrWaEYen/bF
30jFbrfJ+OcqSJJQZO5rqA27ihFpEQH2Qlo297OlJo3yGN2AKVMGMjRERYKRipf6
Wr7JsHYACxxHi1cGtodoBUKuwIDb28UpaIjgTbgU70BwiOYdfO3nU3zDf/sigarz
2HV7OZQYOqoXyf3tQPu/vQ44nompG/zxpdXJAf3dMcZ/HtmAB06a+XROeoq7SkGu
FZllvvIY27x56M6WIw8ZwHJqSfq9u7HGNhJBLRY+dxB6rbAWqDPLyMNvlibzLT+6
H0c+C+Es6qA2HrCt9Oo5nrnMQWw9Xwd/uGdocQBZUY9w7kXzCPIQcXkubhxhwLn6
9SSLNn5nUbJ5xqLZ9f3e
=UCaA
-END PGP SIGNATURE-

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Ratty
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:
http://docs.djangoproject.com/en/1.1/ref/templates/builtins/#truncatewords

Hope that helps,
Ryan

On Dec 30, 1:15 pm, 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 googling shows I'm not the only one, there are tons of people
> writing their own filters to accomplish this, and sure enough a nice
> looking patch submitted two (TWO!) years ago to add a |truncate.
>
> I'd be curious to hear what the reason for not accepting this patch
> is.  String truncation is a pretty common task, and having it built in
> seems like a no-brainer.
>
> For your reference, here's the ticket and patch:
> 
>
> Thanks,
>
> -Nic

--

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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Russell Keith-Magee
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 googling shows I'm not the only one, there are tons of people
> writing their own filters to accomplish this, and sure enough a nice
> looking patch submitted two (TWO!) years ago to add a |truncate.
>
> I'd be curious to hear what the reason for not accepting this patch
> is.  String truncation is a pretty common task, and having it built in
> seems like a no-brainer.

I disagree.

Firstly, as James points out, slice already exists, and the ellipsis
difference between slice and truncate can be easily overcome with
additional code.

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
particularly want to encourage.

I would be marginally more inclined to support a truncate filter that
obeyed word boundaries  i.e., no more than 50 characters, but stop at
the end of the last complete word. However, even with this
modification - what's the use case for an N character truncation? It
can't (or shouldn't be) to make sure that text will fit into a visual
space. You can't guarantee how wide N characters will be at
render-time due to differences in character width. If you want to
truncate for display purposes, you should be looking at CSS overflow
properties or other display-level tricks.

So - put me down as -0 as well. I just don't see that there is a huge
gain in adding another built-in filter. If you really have a need for
this filter, it's easy to support it as an external library.

As for why this patch has languished for so long - one major reason is
that nobody has made an issue of it previously. By my count, this
thread is only the third time that someone has made the case for a
built-in truncate filter, and one of those times was as a late
addition to a thread about adding a completely different bunch of
tags.

Yours,
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.




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

2009-12-30 Thread Ivan Sagalaev
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 to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.