in reply to Link regex

... and yet another way to do it, this time using a subroutine instead of putting everything inside a single RegEx (added readability for those who like that kinda coding style).

my  @aTests = (<DATA>);
    for (@aTests){
        s/\]|\[//gm;        ### strip off sq brackets
        s/^\s*|\s*$//gm;    ### trim whitespace

        ### put fields into array ref and spit out href
        print   &spitHref([split /\s*\|\s*/,$_]);
        print   "\n-----\n";
    }

sub spitHref(){
    my  $aFields    = shift || die"required array ref missing";
    my  $iFlds      = scalar @{$aFields};
    return
    ($iFlds == 0) ? "ERROR: bad data"
    : ($iFlds == 1) ? qq^<a href="$aFields->[0]">$aFields->[0]</a>^
    : ($iFlds == 2) ? qq^<a href="$aFields->[0]">$aFields->[1]</a>^
    : ($iFlds == 3) ? qq^<a href="$aFields->[0]" target="$aFields->[2]
+">$aFields->[1]</a>^
    : 'ERROR: unexpected data'
    ;
}###end_sub

__DATA__
[]
[www.perlmonks.org]
[www1.test.com|test page1]
[www2.test.com|test page2|new]
[www3.test.com|test page3|]
[   www4.test.com    |    test page4     |    ]
[   camelCase|Local Link in Blog | new ]

[download]

Replies are listed 'Best First'.
Re: Re: Link regex
by tachyon (Chancellor) on May 21, 2004 at 12:51 UTC

    There is a significant difference between the code I presented above an this. While the tests were a simple one widget per line I joined the lines and included freeform text. You don't understand the problem if you think you are going to get nice neat [...] widgets in an array. An RE as presented will process a text stream ie a blog page. Your code won't.

    cheers

    tachyon

[reply]
[d/l]

      Although I did use test data almost identical to yours, any similarity between the code I posted and the code you posted is purely coincidental. It's *supposed* to be different, otherwise why post it? That's the whole point. Please note I was responding to the OP, which did not specify a problem domain. Hats off to you for the additional features and assumptions you added in for free on his behalf *applause* ... This brings us to our regularly scheduled standard disclaimer for today...

      Standard Disclaimer For Posted Code:

      • without warranty regarding claims to completeness, fitness or reliability
      • make no assumptions about the given problem domain, unless explicitly stated in the OP
      • are offered as free-of-charge food-for-thought
      • may not have anything to do with what a reasonable person might expect, and might even be a total red herring, and worth less than the zero Euros you paid for it
      • caveat emptor
[reply]

      This is a minor philosophical consideration, totally unrelated to the OP, but relevant to tachyon's comment, hence the additional node.

      If you have heard of the MVC paradigm, you probably are familiar with the basic goals of that programming model. I tend to use a paradigm that is somewhat similar to MVC. Specifically, one of the basic 'rules' is as follows:

      Always make a clear separation between code that *creates* data fields (aka the 'M' part), and code that *outputs* those data fields into a 'fill in the blank' style template (aka the 'V' part).
      Why? Because it is frequent that (over time) you have to make changes to one, independently of the other. Therefore, someone who follows this style is likely to create separate sections of code (eg separate subroutines) to handle these operations separately.

      Given this approach, perhaps it becomes evident why someone would segment out code into separate subroutines, and why one subroutine would expect to get its data fields in prefectly segmented 'widgets' for spitting out a template (and a different subroutine would do the proper 'munging' to make sure they are perfectly segmented).

      Then again perhaps it doesn't become evident. Oh well. FWIW. YMMV. Thanks for coming to the show. Please tip your waitress generously. Have a nice day.

[reply]

In Section Seekers of Perl Wisdom