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
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
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/buil
-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 D
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
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
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
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
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 lin
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
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
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 d
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 s
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",
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 understo
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 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 unsubs
On 12/30/09 1:02 PM, "Ian Kelly" wrote:
> 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 pe
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
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 fin
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 boo
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 percentag
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 shou
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 fro
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 fea
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
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
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 v
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 w
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
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. Al
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 p
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
>
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, D
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
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/
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 th
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'
> 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.
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 sing
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 decompose
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 th
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
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
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 addi
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 str
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
dj
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 th
On Thu, Dec 31, 2009 at 12:54 AM, Jerome Leclanche wrote:
> 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 m
49 matches
Mail list logo