With the increasing use of HTML validation from a number of directions (understatement), it seems we cannot get away with stuff like we used to. I ran across this today and had to correct my Perl code. For instance:

Code:

$mylink "<a href='/index.html'>home</a>\n"; print "<div align='center'>My text and other stuff</div>\n";

The HTML validator did not like this one, little bit. So, when we use the basic print command or have HTML in a variable, the escape slash has to be used and double quotes must replace the single ones, like this:

Code:

print "<div align=\"center\">My text and other stuff</div>\n"; $mylink "<a href=\"/index.html\">home</a>\n";

The other thing that came up was a line breaking and no linebreak code visible. This happened, again in a link, where a list also had some redefinition and splitting up code in. The HTML was actually correct. Perl however, during the processing, broke the link in two just before the double quote (it had picked up the actual linebreak in the file it was reading). This resulted in chain or errors (quite a long chain in fact) during the validation. To overcome that I used
Code:

$variable =~s/\n//g;

inside the foreach loop. That stopped the "invisible break" and all subsquent errors. My validation was clean and I happily saw the "No Errors Present" notice.

Looks like some of us (including me) will have to clean up our coding act when it comes to HTML in our scripts. Especially now that some search engines are starting to use HTML code validation in their robot programs.

Use the qq operator for double-quoted stings:

print qq{<div align="center">My text and other stuff</div>\n};

makes for much cleaner perl code. You could also use heredocs but I don't use them myself.

You should use the chomp() function when reading in data from a file.

While the html validation is a concern, you also need to brush up on your perl.


True..

Using the qq without a tilde is new to me. When I used the tilde I got errors, so used the standard print as mentioned earlier. Learn something new every day. Using the qq that way will help a lot as I often have links coming off a ffdb or a file.

As a designer (rather than a progammer) it's good to find a new way of doing something.

with perl you are free to choose almost any delimiters you want:

qq(....)
qq{....}
qq[....]
qq~....~
qq#....#
qq!....!
etc
etc
etc

if you use paired brackets you must use the left and right bracket, if you use a character you use the same character.

You might also want to look into using templates, which is very much in vogue these days.


The fascinating thing is that if you use brackets or braces, it actually counts the brackets and braces within the expression too - counts 'em out and counts 'em in - so that you can write some REALLY horrid code  

on 09/29/07 at 05:34:28, Graham Ellis wrote:

The fascinating thing is that if you use brackets or braces, it actually counts the brackets and braces within the expression too - counts 'em out and counts 'em in - so that you can write some REALLY horrid code

Graham,

You're just too easily fascinated.  

Actually the behavior is quite strange and not well documented and can lead to some confusion. The whole concept of delimiters and type definitions can lead to some stange code:

$foo =~ /$bar[$this[$n]]$baz{1}/;

are those arrays indexes or character classes? Is that a hash key or a quantifier? Only perl knows....  

Duh   I think you guys are losing me  

on 09/29/07 at 20:57:18, TedH wrote:

Duh   I think you guys are losing me

Would you please try and keep up with the conversation.  

Never mind us, we probably need vacations. I need to flush my brain cells of residual perl minutia.  A quicky to Las Vegas is in the near future I suspect.  

on 09/29/07 at 20:57:18, TedH wrote:

Duh   I think you guys are losing me

Actually, Ted, I take the view that when code gets so hard to follow that even the geekier once of us have trouble seeing what the brecakets actually mean ... that it's time to simplify.

I would take Kevin's example and "Suck it and see" to actually work out what it did.  But then as you're American and he's from the USA, I would probably find that such a saying was unknown to you or perhaps a bit naughty.

It all come down to writing code that's appropriate for the maintainer!

I think a lot of times it's what we are used to and where in the code some items are being used. As Graham well knows, I'm a KISS rule supporter, so if something works - leave it alone and then change if you find a better way (as is the case here).

The main theme here has been making sure our code, when viewable over the web, is as error free as possible.

If'n they don't see, it can be anything as long as it works and if'n they do - it had better be purdy  

---