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
