I have so far gathered a code-
<pre[% ' id="comment_text_' _ count _ '"' IF mode == "edit" %]>
[% count = 0 %]
[% increment = 1 %]
[%- text= wrapped_comment FILTER quoteUrls(bug.bug_id) -%]
[% IF (matches =
text.match('([\w./]+)[\s|\n]+([\d.]+|NONE)[\s|\n]+([\d.]+|NONE)')) %]
[% FOREACH match = matches %]
[%- text= text.replace('match.\$count','<a href="
http://svn/cvsweb/cvsweb.cgi";>abc</a>') -%]
[% END %]
[% count = count + increment %]
[% END %]
[%- text -%]
But still not able to get the right code replace i.e in match regex.
Can anyone suggest where i am going wrong.
On Wed, Apr 15, 2009 at 11:55 AM, Kapila Kohli <[email protected]>wrote:
> Hi,
> I am new to Template editing. Currently working on editing
> Bugzilla/Template/comments.html.tmpl.
> I would like to add a code for pattern:-
>
> FILES CHECKED IN:
> orion/WEB-INF/src/com/mmt/hotels/seo/beans/Video.java NONE 1.1.2.1
> orion/WEB-INF/src/com/mmt/hotels/seo/beans/Review.java NONE 1.1.2.1
> orion/WEB-INF/src/com/mmt/hotels/seo/beans/Area.java NONE 1.1.2.1
> orion/WEB-INF/src/com/mmt/hotels/seo/beans/CategoryHotel.java NONE
> 1.1.2.1
> etc etc
>
> Make Filename, revision a hyperlink.
>
> tried code:
>
> [% reponm = ' http://svn/cvsweb/cvsweb.cgi' %]
> [% con = "" %]
>
> <pre[% ' id="comment_text_' _ count _ '"' IF mode == "edit" %]>
> [%- text= wrapped_comment FILTER quoteUrls(bug.bug_id) -%]
>
> [% IF
> text.match('/([\w./]+)[\s|\n]+([\d.]+|NONE)[\s|\n]+([\d.]+|NONE)/g') %]
> [% SET @matches = ' value ' %]
> [% text= text.replace(' value ','<a
> href="$reponm/$value[con]">$value[con+]</a>') %]
> [% con++ %]
> [% END %]
>
> [%- text -%]
> </pre> </div>
> [% END %]
>
> But it doesn't seem to be working,can anyone help me on this?
> Thanks in advance.
> Regards
>
> On Mon, Apr 13, 2009 at 4:30 PM,
> <[email protected]>wrote:
>
>> Send templates mailing list submissions to
>> [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://mail.template-toolkit.org/mailman/listinfo/templates
>> or, via email, send a message with subject or body 'help' to
>> [email protected]
>>
>> You can reach the person managing the list at
>> [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of templates digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Truncate that preserves HTML tags ? (Lee.M)
>> 2. Re: Truncate that preserves HTML tags ? (Lee.M)
>> 3. Re: Truncate that preserves HTML tags ? (Lee.M)
>> 4. Re: Truncate that preserves HTML tags ? (Lee.M)
>> 5. Re: Truncate that preserves HTML tags ? (Lee.M)
>> 6. Re: Truncate that preserves HTML tags ? (Ashley)
>> 7. Re: Truncate that preserves HTML tags ? (Ashley)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 12 Apr 2009 14:12:44 -0500
>> From: "Lee.M" <[email protected]>
>> Subject: Re: [Templates] Truncate that preserves HTML tags ?
>> To: templates <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> > If HTML::Obliterate were to handle all these corner cases using
>> > regexp's, then HTML::Strip's claims may actually be correct.
>>
>> Perhaps, I think the goals are slightly different though so you'd
>> never need that much in the way of regexes, plus the memory leak I
>> stumbled across is a pretty bad thing.
>>
>> > It appears the code in the HTML::Obliterate is a very simple couple
>> > of regexp's that won't handle all cases.
>>
>> Then you should submit an rt so the author will be aware of it
>>
>> > After looking at the source, I wouldn't even bother using the module
>> > since you could just use the two simple regexp's.
>>
>> The point is to re-use code though. By way of hyperbole, for example,
>> you have 10,000 places you rip out HTML.
>>
>> Now lets say you find that a slight change in the regexes make them
>> even better. (IE That it will handle the "corner" case you mentioned)
>>
>> If you used the module, you update the module and all 10,000 places
>> magically work.
>>
>> If you did not use the module you have to make sure you update all
>> 10,000 places you use the regex.
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sun, 12 Apr 2009 14:16:28 -0500
>> From: "Lee.M" <[email protected]>
>> Subject: Re: [Templates] Truncate that preserves HTML tags ?
>> To: templates <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> On Apr 10, 2009, at 4:46 PM, Josh Rosenbaum wrote:
>>
>> > Lee.M wrote:
>> >>> HTML::Parser can usually handle improper HTML better at the
>> >>> expense of speed.
>> >> I think it uses HTML::Truncate under the hood
>> >
>> > I think you meant HTML::Truncate uses HTML::Parser under the
>> > hood. :P (I checked and that appears to be true.)
>>
>> Yes, I apologize if that was not apparent from the context of the
>> inline reply.
>>
>> > HTML::Parser is awesome. I've used it for all sorts of things.
>>
>> Very true :)
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sun, 12 Apr 2009 15:20:58 -0500
>> From: "Lee.M" <[email protected]>
>> Subject: Re: [Templates] Truncate that preserves HTML tags ?
>> To: templates <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>>
>> On Apr 12, 2009, at 2:12 PM, Lee.M wrote:
>>
>> >> If HTML::Obliterate were to handle all these corner cases using
>> >> regexp's, then HTML::Strip's claims may actually be correct.
>> >
>> > Perhaps, I think the goals are slightly different though so you'd
>> > never need that much in the way of regexes,
>>
>> Let me elaborate on what I mean by that:
>>
>> HTML::Strip isn't just stripping, it's formatting too: (<script>js</
>> script> is completely removed, <br> is turned into space, &entity; is
>> turned into the character, etc etc)
>>
>> So it requires much more logic and resources, which is fine, it is
>> what it is.
>>
>> HTML::Obliterate strips HTML w/ no attempt to try an understand what
>> you mean by it. So it requires much less logic and resources, which is
>> also fine, it is what it is.
>>
>> If I were trying to make sure a user didn't submit any HTML I'd rip it
>> out w/ HTML::Obliterate, if I wanted to turn HTML into some sort of
>> displayable text I might use HTML::Strip.
>>
>> I guess my main problem with HTML::Strip is:
>> - the name is misleading
>> - it has a memory leak
>> - it requires too many steps (create an object, parse(), eof() ,
>> parse, eof, parse, eof, for one thing)
>> - What does eof() have to do with formatting a line?
>> (reset_object() would make more sense no?)
>>
>> That said, if I wanted transformation of HTML into text, it'd do the
>> job nicely but it isn't done in a 'quick and brutal manner' it's done
>> in a complex and methodical manner, which, again, is fine because it
>> is what it is ;p
>>
>> > plus the memory leak I stumbled across is a pretty bad thing.
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sun, 12 Apr 2009 19:49:44 -0500
>> From: "Lee.M" <[email protected]>
>> Subject: Re: [Templates] Truncate that preserves HTML tags ?
>> To: templates <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> >> It appears the code in the HTML::Obliterate is a very simple couple
>> >> of regexp's that won't handle all cases.
>> >
>> > Then you should submit an rt so the author will be aware of it
>>
>> I let the author know and he says he's looking into it. He says to
>> please let him know of anything version 0.3 doesn't handle (once he's
>> uploaded it to CPAN of course ;p)
>>
>> What a productive conversation!
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Sun, 12 Apr 2009 20:01:30 -0500
>> From: "Lee.M" <[email protected]>
>> Subject: Re: [Templates] Truncate that preserves HTML tags ?
>> To: templates <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> > It is for all source appearances something that was meant to go in the
>> > Acme namespace and its regexes are really quite bad.
>>
>> I beg to differ, it's quite useful in certain circumstances. Care to
>> share what "really quite bad" means specifically or are you just
>> blindly stating unfounded opinion as fact?
>>
>> > In general, never use a regex where a parser exists. It's false
>> > economy and much harder to get right than spending an hour or two
>> > learning the interface for a good parser.
>>
>> Depends on what you're using it for. If it's a complex task, sure use
>> a more complex module, if it's a simple task use a simple module (or a
>> complex module if you wish), whatever is fine :)
>>
>> At the very least, a module encapsulating simple logic is still good
>> to use for consistency and maintenance sake.
>>
>> > There is a TT2 filter recipe in HTML::Truncate's Pod too. :)
>>
>> Yep, that is why I recommended initially :)
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Sun, 12 Apr 2009 17:48:04 -0700
>> From: Ashley <[email protected]>
>> Subject: Re: [Templates] Truncate that preserves HTML tags ?
>> To: "Lee.M" <[email protected]>
>> Cc: templates <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed
>>
>> On Apr 12, 2009, at 1:20 PM, Lee.M wrote:
>> > On Apr 12, 2009, at 2:12 PM, Lee.M wrote:
>> >
>> >>> If HTML::Obliterate were to handle all these corner cases using
>> >>> regexp's, then HTML::Strip's claims may actually be correct.
>> >>
>> >> Perhaps, I think the goals are slightly different though so you'd
>> >> never need that much in the way of regexes,
>> >
>> > So it requires much more logic and resources, which is fine, it is
>> > what it is.
>> >
>> > HTML::Obliterate strips HTML w/ no attempt to try an understand what
>> > you mean by it. So it requires much less logic and resources, which is
>> > also fine, it is what it is.
>>
>>
>> It is for all source appearances something that was meant to go in the
>> Acme namespace and its regexes are really quite bad. I would not
>> recommend using or even trying to patch this thing. It's fairly
>> trivial to strip HTML with something like HTML::TokeParser or
>> XML::LibXML and it is going to work right.
>>
>> In general, never use a regex where a parser exists. It's false
>> economy and much harder to get right than spending an hour or two
>> learning the interface for a good parser.
>>
>> There is a TT2 filter recipe in HTML::Truncate's Pod too. :)
>>
>> -Ashley
>> --
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Sun, 12 Apr 2009 18:27:29 -0700
>> From: Ashley <[email protected]>
>> Subject: Re: [Templates] Truncate that preserves HTML tags ?
>> To: "Lee.M" <[email protected]>
>> Cc: templates <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>>
>> On Apr 12, 2009, at 6:01 PM, Lee.M wrote:
>> >> It is for all source appearances something that was meant to go in
>> >> the
>> >> Acme namespace and its regexes are really quite bad.
>> >
>> > I beg to differ, it's quite useful in certain circumstances. Care to
>> > share what "really quite bad" means specifically or are you just
>> > blindly stating unfounded opinion as fact?
>>
>> I was just blindly stating unfounded opinion as fact. Now that you
>> called me on it I'm forced to admit it. You should totally use
>> this in your code. Just because the author doesn't seem to understand
>> what the m and s flags mean in a regular expression or thinks that
>> the only meaningful sub in a serious module should have 12 aliases
>> called with goto... you should totally use this. Entities are for
>> chumps, after all. Who needs all those fancy European letters
>> and stupid typographical marks? ASCII got us to the Moon, why
>> should we abandon it now?
>>
>> >> In general, never use a regex where a parser exists. It's false
>> >> economy and much harder to get right than spending an hour or two
>> >> learning the interface for a good parser.
>> >
>> > Depends on what you're using it for. If it's a complex task, sure use
>> > a more complex module, if it's a simple task use a simple module (or a
>> > complex module if you wish), whatever is fine :)
>>
>> It's a broken module and a broken approach and since it's, for all its
>> 12 aliases, still only wrapping a single regular expression it
>> obfuscates
>> what is really only a single regular expression and thus makes finding
>> bugs much harder.
>>
>> Here are some of the ways the module breaks-
>>
>> >perl -MHTML::Obliterate -le 'print HTML::Obliterate::kill_html
>> (shift)' '© 1999'
>> 1999
>> >perl -MHTML::Obliterate -le 'print HTML::Obliterate::kill_html
>> (shift)' ' 1 < 2 and 3 > 5'
>> 1 5
>> >perl -MHTML::Obliterate -le 'print HTML::Obliterate::kill_html
>> (shift)' '<img src="..." alt="<hi!>" />'
>> " />
>>
>> So, when you recommended this to everyone could you share what
>> you found so good about the code or were you just blindly substituting
>> personal opinion for valid judgement?
>>
>> -Ashley
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> templates mailing list
>> [email protected]
>> http://mail.template-toolkit.org/mailman/listinfo/templates
>>
>>
>> End of templates Digest, Vol 20, Issue 11
>> *****************************************
>>
>
>
_______________________________________________
templates mailing list
[email protected]
http://mail.template-toolkit.org/mailman/listinfo/templates
