[ic] Filter tag and html - Patch for Interpolate.pm

[Sandy Thomson]

Daniel Davenport wrote:

>  
>
>>>>sandy at scotwebshops.com 03/24/05 10:38AM >>>
>>>>        
>>>>
>>Hi,
>>We were using the character limit thing on the filter tag, and were 
>>getting frustrated that it treated html entites as > 1 characters,
>>    
>>
>and 
>  
>
>>if there were html tags in the string, it didnt close the tags.
>>
>>    
>>
><snip example>
>  
>
>>Basically this can leave bad html code that will not validate.
>>
>>After a morning of programming, I have made this code correctly close
>>    
>>
>
>  
>
>>open html tags (ignores self closed tags) and treat html entites as
>>    
>>
>one 
>  
>
>>character.
>>    
>>
>
>This isn't a half bad idea, except that it leads to strings that can be
>quite a bit longer than the x characters implied in a [filter x]... tag.
> This patch makes [filter x] effectively useless for limiting the length
>of code that might need its size limited. 
>  
>

I agree, just didn't think about what I was typing yesterday. The 
example was for the filter tag with a number and a dot.


>  
>
>>Examples:
>>[filter 20.]The sheep the sheep theyre gaining on me![/filter] = 'The
>>    
>>
>
>  
>
>>sheep the sheep &hellip;'
>>    
>>
>
>This one would be fine if you replaced '20.' with '20'
>  
>

This was meant to be an example to show it works pretty much the same as 
before if you dont have html tags/entites. But what if there was no 
overflow in [filter 20]? The code that calls the filter wouldn't know 
whether to draw the '...' ?

>  
>
>>[filter 20.]The sheep <strong>the sheep theyre gaining on 
>>me</strong>![/filter] = 'The sheep <strong>the sheep
>>    
>>
></strong>&hellip;'
>
>This one, though, would lead to a string around 45 characters long. 
>Kinda defeats the purpose of limiting the size to 20 characters.
>  
>

But I thought it was useful when you wanted some text to display in a 
fixed width area of an html page, or something&hellip;  :-)

>And a pathological example of my own....
>
>[filter 10]<strong>T</strong><strong>h</strong><strong>e</strong>
><strong>s</strong><strong>h</strong><strong>e</strong><strong>e</strong><strong>p</strong>[/filter]
>
>which--if your examples are right--won't chop anything at all, even
>though the content is nearly 15 times as long as i'd expect it to be.
>
>I would suggest that you separate the checks, so that /^(\d+)\.$/ and
>/^(\d+)$/ are checked separately.  Unless there's a dot, the filter
>should act as it did before; that is, chop off any characters after the
>x'th, even if it involves breaking HTML tags.  Otherwise, any code that
>relies on it to limit a field's real length might run into trouble.
>
>BTW....that sure is a lot of code.  :)
>  
>

I guess it depends on the context. If you want to filter the actual 
amount of characters for a db insert then obviously it makes sense to 
have the standard filter, however the filter with the dot at the end, i 
see little use for it apart from truncating text for presentation in a 
web page.

In the filter section of Interpolate.pm, there is already another if 
statement for the case without the dot. (i.e it tries to match /^\d+\/. 
first, if that doesnt match then it tries to match /^\d+/). I have left 
the if statement without the dot alone.

You are more than welcome to chop the code down (post it to me if you 
do), i thought i should give the characters meaningful names rather than 
$x, $a, $v etc, and space everything out so it is readable. Actually, i 
might have another hack at the code today and try to optimise it a bit, 
was more concerned about getting it to work properly yesterday!

Cheers.

Sandy.