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

[Sandy Thomson <suppressed>]

Daniel Davenport wrote:

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

_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users