I don't want to attempt to pollute Django's beautiful template library namespace with garbage, but I do see a legitimate value for a linebreaksli template filter. It does just what it says - converts a string with linebreaks into a set of list items. Sometimes, a <p> tag just doesn't do the same thing, especially if you want to number the items with an <ol>. My code is below. It wouldn't take too much to convert it to a Django template filter. What does everyone think?
def linebreaksli(value): "Converts strings with newlines into <li></li>s" value = re.sub(r'\r\n|\r|\n', '\n', value) # normalize newlines lines = re.split('\n', value) lines = ['<li>%s</li>' % line for line in lines] return '\n'.join(lines)
> On Jun 20, 5:03 pm, "rokclim...@gmail.com" <rokclim...@gmail.com> > wrote: > > My code is below. It wouldn't take too much to > > convert it to a Django template filter. What does everyone think? > Interesting filter. > Personally, I'm not sure this is useful enough for core.
rokclim...@gmail.com wrote: > I don't want to attempt to pollute Django's beautiful template library > namespace with garbage, but I do see a legitimate value for a > linebreaksli template filter.
A more general solution might be to have a linebreakstag filter that takes arguments:
{{ mytext|linebreakstag:"<li>,</li>" }}
This tag would be able to handle what the linebreaksbr filter does too:
{{ mytext|linebreakstag:",<br />" }}
--
This has got me thinking though, do we even really need the two linebreaks filters that exist now?
IMO, the linebreaks filter does too much when it wraps the string in tags. Those <p> tags should go in the template, not done by the filter. (Looking at tickets, this would fix #4560 [1].) So, I think the linebreaks filter should do what linkbreaksbr does, and linkbreaksbr should go away. Then, the new linebreaks could take arguments for the start and end of each line. (This would solve the OP's problem and also #4573 [2].) Something like:
text = "hello\nworld"
{{ text|linebreaks }} becomes:
hello<br />world
{{ text|linebreaks:"<li>,</li>" }} becomes:
<li>hello</li> <li>world</li>
{{ text|linebreaks:",<hr />" }} becomes:
hello<hr />world
To get the old functionality of {{ text|linebreaks }}, you would have to do <p>{{ text|linebreaks }}</p>.
On Thu, 2007-06-21 at 19:04 -0500, Gary Wilson wrote:
Hey .. you're back. :-) Hope you had a nice break.
> rokclim...@gmail.com wrote: > > I don't want to attempt to pollute Django's beautiful template library > > namespace with garbage, but I do see a legitimate value for a > > linebreaksli template filter.
> A more general solution might be to have a linebreakstag filter that > takes arguments:
> {{ mytext|linebreakstag:"<li>,</li>" }}
> This tag would be able to handle what the linebreaksbr filter does too:
> {{ mytext|linebreakstag:",<br />" }}
-1.
I don't like adding lots of customisation options to things like this. It is *so* trivial to write a filter that does this if somebody really wants that feature, but it isn't universally useful enough to warrant the extra complexity. Turning line breaks into list items, for example, is not a particularly semantically equivalent change.
> This has got me thinking though, do we even really need the two > linebreaks filters that exist now?
> IMO, the linebreaks filter does too much when it wraps the string in > tags. Those <p> tags should go in the template, not done by the > filter. > (Looking at tickets, this would fix #4560 [1].) So, I think the > linebreaks filter should do what linkbreaksbr does, and linkbreaksbr > should go away.
People can just not use filters they don't like. They don't have to go away. That's backwards-compatible.
Sure, there are a bunch of filters that show Django's history: they were written to scratch some itch at Lawrence and made it into core as part of open-sourcing the project. I don't really care whether they stay or go, but would favour "stay" simply to avoid breaking existing templates. However, that shouldn't be used as a doorway to introduce every possible type of filter variation people might use once or twice. Instead, we make it easy to add custom ones.