Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

(tedv)Re: Template system and substitution

by tedv (Pilgrim)
on Nov 17, 2000 at 03:23 UTC ( #42115=note: print w/replies, xml ) Need Help??

in reply to (tye)Re: Template system and substitution
in thread Template system and substitution

Haven't you read Death to Dot Star yet? You will have much trouble matching something like [{ [{ }] }]


Replies are listed 'Best First'.
(tye)Re2: Template system and substitution
by tye (Sage) on Nov 17, 2000 at 04:05 UTC

    Um, if we had single-character delimiters, then the suggestion in Death to Dot Star would apply; use a negated character class in place of "dot":

    m# \[ [^\]]* \] #x
    but that isn't the case here.

    If you are wanting me to do that complex trick to avoid matching a closing (or even opening) delimiter in the middle, then I don't think you read the thread. Lots of good people tried and failed to get it right. I don't recommend doing that trick since I've never seen it proposed (even by amazing people) without someone finding an error in it.

    Plus, it wouldn't gain us anything in this case. If I see an opening delimiter in this situation, I want to force the match to start there. It would be an error to have extra, unmatch starting delimiters. We aren't trying to parse English here.

    As for matching nested blocks, that pretty much violates the original design. For defensive programming, I'd probably have the expand() routine look for and warn of opening delimiters in the match string since these might indicate that a closing delimiter was dropped or munged. But to be completely defensive would require more work than that.

            - tye (but my friends call me "Tye")
      Well understandably the paranethesis matching of this is extremely difficult. It's my intuition that regex isn't the right solution-- reformulating the problem is. :) At the very least, you could just rip out all []s and get back to single character pairing with nesting. What strikes me as odd is why the data would even be in that format to begin with... Surely you could come up with a more meaningful output format...


        Well if you code up an alternate way to parse this, then I'd be interested in seeing a benchmark comparison. I think my solution was pretty simple, efficient, and correct.

        My suggestion would be to use a templating module (probably Template Toolkit based on what others say about these things). But if that isn't acceptable for whatever reasons, I still stand by my suggestion as quite reasonable.

        I don't see how riping out brackets would help much since there will probably be plenty of brackets that aren't delimiters both inside and outside of the delimited blocks.

        Thinking of how I'd catch all unmatched delimiters, I'd probably do this:

        my %start= qw( [( )] [| |] [{ }] ); my %end= reverse %start; my $expect= ""; # Closing delimiter we expect, if any. my $code; for my $chunk ( split m#( \[ [(|{] | [)|}] \] )#x, $template ) { if( "" eq $expect ) { if( $start{$chunk} ) { $expect= $start{$chunk}; $code= ""; } else { warn "Unmatched $chunk\n" if $end{$chunk}; print $chunk; } } else { if( $chunk eq $expect ) { print expand( $code ); $expect= ""; } else { $code .= $chunk; warn "Found $chunk inside $end{$expect} $expect block\n" if $start{$chunk} || $end{$chunk}; } } }

                - tye (but my friends call me "Tye")
Re: (tedv)Re: Template system and substitution
by jepri (Parson) on Nov 17, 2000 at 04:36 UTC
    In the event that you did have nested tags, you would probably want to go for a recursive function. Something like:

    sub parse { if ( $_[0] =~ /\[(.*)$/ ) { parse($1)} else { if ($_[0] =~ /(.*)\]/ ) { #Do your replace on $1 }else{ die "Unmatched brackets found"; } } }

    or something like that anyway. But you probably wouldn't want nested brackets in a template system.


      But you probably wouldn't want nested brackets in a template system.
      I would =P

      UPDATE: Geez I was just trying to be goofy and now I have to justify this ;P

      OK, if you are just expressing basic values with your template system, you don't need nesting. If you are just enclosing code in another language you don't need nesting. If, however, you wish your template engine could do some light-weight decisions without having to resort to heavy code you might like having blocks like this:

      [? variable_that_might_exist ?] HTML that uses the array that [$ variable_that_might_exist $] flags the existence of... [@ maybe_array @] [/ variable_that_might_exist /]

      Worse, you may wish to emulate a light-weight version of a hash in template code like:

      [% hash_name -> [$ key_1 $] %]

      Sure it's stupid and there might be better ways but I have done something like it before (when I invented my own template system 4 years ago, where-o-where was Text::Template then?) and found that it was MUCH easier and safer to give my HTML people a seriously lightweight but "codeable" template system verses a glorified s/\[\$([a-zA-Z0-9_.-]+)\$\]/$hash{$1}/g system.

      Tho there is no shame in that system =)

      $you = new YOU;
      honk() if $you->love(perl)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://42115]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (8)
As of 2017-02-21 21:23 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (319 votes). Check out past polls.