Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

2008-06-05 Thread Mike Scott
Ahh my greatest apologies - not expected behaviour, nor compliant behavour.

Teach me for skim reading.

On Thu, Jun 5, 2008 at 11:31 AM, Jeff Anderson <[EMAIL PROTECTED]>
wrote:

> Mike Scott wrote:
>
>> Marty:
>>
>> If you read his post you'll see he is infact getting a 500 Server error,
>> and
>> not a spam filter error. 500 Server errors happen when something goes
>> wrong,
>> not when spam is filtered.
>>
>>
> The way that this ticket system is set up, you do indeed get a 500 Server
> error when you are marked as spam; pasted:
>
> Internal Server Error
> 500 Internal Server Error (Submission rejected as potential spam (Akismet
> says content is spam))
> TracGuide — The Trac User and Administration Guide
>
> This is re-creatable by simply being anonymous (clear your cookies, or use
> a different browser!) and attempting to post a ticket.
>
>
> Jeff Anderson
>
>

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



Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

2008-06-04 Thread Jeff Anderson

Mike Scott wrote:

Marty:

If you read his post you'll see he is infact getting a 500 Server error, and
not a spam filter error. 500 Server errors happen when something goes wrong,
not when spam is filtered.
  
The way that this ticket system is set up, you do indeed get a 500 
Server error when you are marked as spam; pasted:


Internal Server Error
500 Internal Server Error (Submission rejected as potential spam 
(Akismet says content is spam))

TracGuide — The Trac User and Administration Guide

This is re-creatable by simply being anonymous (clear your cookies, or 
use a different browser!) and attempting to post a ticket.



Jeff Anderson



signature.asc
Description: OpenPGP digital signature


Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

2008-06-04 Thread Mike Scott
Marty:

If you read his post you'll see he is infact getting a 500 Server error, and
not a spam filter error. 500 Server errors happen when something goes wrong,
not when spam is filtered.

On Thu, Jun 5, 2008 at 5:40 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:

>
> On Wed, Jun 4, 2008 at 1:21 PM, Aral Balkan <[EMAIL PROTECTED]> wrote:
> > Unfortunately, I don't think your ticketing system likes me. I'm
> > getting: 500 Internal Server Error (Submission rejected as potential
> > spam).
>
> Right on the new ticket screen, under the big heading labeled "Read
> this first" you'll find the following line:
>
> "If you're getting rejected by the spam filter, we apologize! The best
> way to avoid that is to register for an account and make sure you're
> logged in."
>
> -Gul
>
> >
>

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



Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

2008-06-04 Thread Marty Alchin

On Wed, Jun 4, 2008 at 1:21 PM, Aral Balkan <[EMAIL PROTECTED]> wrote:
> Unfortunately, I don't think your ticketing system likes me. I'm
> getting: 500 Internal Server Error (Submission rejected as potential
> spam).

Right on the new ticket screen, under the big heading labeled "Read
this first" you'll find the following line:

"If you're getting rejected by the spam filter, we apologize! The best
way to avoid that is to register for an account and make sure you're
logged in."

-Gul

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



Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

2008-06-04 Thread Aral Balkan

Hi Russell,

Unfortunately, I don't think your ticketing system likes me. I'm
getting: 500 Internal Server Error (Submission rejected as potential
spam).

Here's the text of the ticket. If anyone can post it up for me, I'd be
grateful. Thanks!

Aral


The truncatewords filter currently adds faux ellipses (three dots) to
every truncated string. This is not ideal for several reasons:

1. It should use a true ellipsis (\u2026) instead of three dots.

2. The filter would be far more useful if adding ellipses was an
_option_.

Use case for number 2:

I have  a person's full name: "Aral Balkan" and I want to greet them
by their first name. I should be able to write the following in a
template to indicate that an ellipsis should not be added:

{{{
Hello, {{personName|truncatewords:1:False}}, how are you?
}}}

The truncatewords filter would simply have its signature altered and
call utils.text.truncate_words with the altered signature, passing the
second argument:

{{{
def truncatewords(value, arg, add_ellipsis=True):
"""
Truncates a string after a certain number of words.

Argument: Number of words to truncate after. And, (optional)
whether or not to add an ellipsis.
"""
from django.utils.text import truncate_words

try:
length = int(arg)
except ValueError: # Invalid literal for int().
return value # Fail silently.

return truncate_words(value, length, add_ellipsis)
}}}

And utils.text.truncate_words would be changed to:

{{{
def truncate_words(s, num, add_ellipsis=True):
"Truncates a string after a certain number of words."
s = force_unicode(s)
length = int(num)
words = s.split()
if len(words) > length:
words = words[:length]

if add_ellipsis:
if not words[-1].endswith(u'…'):
words.append(u'…')

return u' '.join(words)
}}}

Since we're using a unicode literal, utils.text would also have to
specify the encoding:

{{{
# This Python file uses the following encoding:
utf-8
}}}

Unfortunately, we don't have multiple arguments in filters, so the
above will not currently work. However, because this is an actual use
case, I do need to implement this somehow and my options are either
to:

1. Handle the truncation in my view and pass only the first name. This
leads to duplication of code. And it's debatable how much this code
actually belongs in my view function.

2. Write a separate filter (truncatewordswithoutellipsis) with an
inelegant name and result in duplication of code.

3. Have truncatewords accept a string and parse it using a delimiter.
(If having multiple arguments is seen an overly-complex for filters,
this is doubly so as it makes the syntax way more confusing by robbing
the integer length argument and the boolean add_ellipsis argument of
their actual datatypes and thus weakening the intent of the code).

4. Create a convention that works with the current system and only
requires one argument.

In this case, I decided to go with number 4 and create the following
convention:

If the argument provided to truncatewords is positive, it ads
ellipsis, if it is negative, it does not.

{{{
Hello, {{personName|truncatewords:1}},
}}}

Hello, Aral ...,

{{{
Hello {{personName|truncatewords:"-1"}},
}}}

Hello, Aral,

Of course, this solution is quite ridiculous and the syntax is in no
way intuitive. It is a direct result of the artificial constraint of
not being able to use more than one argument in a filter (and not the
template-author's needs). Within the current rules for filters,
however, it makes complete sense and may even be seen as an elegant
solution given the one-argument constraint (which is to say that, ipso
facto, the current constraint does not make much sense.)

I am aware of and completely agree with Django's philosophy of keeping
templates simple but, in this case, the limitation of having just one
argument for a filter actually _complicates_ templates more than if
filters could take more than one argument.

The refactored truncatewords filter from the solution above is below
and uses the utils.text.truncate_words function listed earlier:

{{{
def truncatewords(value, arg, add_ellipsis=True):
"""
Truncates a string after a certain number of words.

Argument: Number of words to truncate after. And, (optional)
whether or not to add an ellipsis.
"""
from django.utils.text import truncate_words

try:
length = int(arg)
except ValueError: # Invalid literal for int().
return value # Fail silently.

if length<0:
add_ellipsis = False;
length = abs(length)

return truncate_words(value, length, add_ellipsis)
}}}

Please feel free to commit this (diffs at end) if you feel that having
words truncated without ellipses is a use case that other developers
may have also. However, I do hope instead that we can address the
bigger problem here which is this:

Filters are currently artificially constrained to have a single
argument and this 

Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

2008-06-04 Thread Aral Balkan

Hi Russell,

Cool, thanks -- will post it as a ticket now. And apologies for the
messed up syntax in the previous post -- will clean it up for the
ticket.

Aral

On Jun 4, 12:28 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On Wed, Jun 4, 2008 at 6:20 PM, Aral Balkan <[EMAIL PROTECTED]> wrote:
>
> > Please feel free to commit this (diffs at end) if you feel that having
> > words truncated without ellipses is a use case that other developers
> > may have also. However, I do hope instead that we can address the
> > bigger problem here which is this:

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



Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

2008-06-04 Thread Russell Keith-Magee

On Wed, Jun 4, 2008 at 6:20 PM, Aral Balkan <[EMAIL PROTECTED]> wrote:
>
> Please feel free to commit this (diffs at end) if you feel that having
> words truncated without ellipses is a use case that other developers
> may have also. However, I do hope instead that we can address the
> bigger problem here which is this:

Hi Aral,

Thanks for the contribution, but this should be submitted as a ticket,
rather than posted to the mailing list. Tickets act as a permanent
archive of suggestions that have been made; messages on a mailing list
tend to get lost after a while.

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