• you're doing it to teach yourself something
• you're doing it just for fun
• the existing solutions not only don't work for you, but also don't serve as a starting point for you to build on because they solve a different problem
• when the existing solutions don't perform well enough
• when the existing solutions are not maintained well enough and are too difficult to start maintaining yourself

It's important to know that if you reimplement a publicly available solution which has lots of support from the community, you are taking a pass on all of that support.

The downside of reinventing wheels when you don't know what's out there is that you could be duplicating work and doing a worse job of it. Even if you duplicate what you know about, you're still doing things a new and different way that people will be slower to help you develop. That's because they're all busy enough learning, using, and helping people with the existing, popular tool sets.

If your solution is good enough that it overcomes these obstacles, that's great. Expecting it to be warmly accepted over and above the established alternatives without showing people why it's better is a bit presumptuous.

If you can show us how great your system is, but it takes lots of examples, then perhaps a tutorial, Perl.com or use.Perl.org article, a book, or a website showing us how to use it and why it is worth learning despite extant alternatives, then you'd probably get much better traction.

This may very well fit your needs better than any of the existing solutions. You've not said why it does, though. You also seem to be implying it will meet the needs of others better than the existing solutions, and again we don't see why.

As a disclaimer, I'll say that I, personally, use a home-grown application framework quite regularly. I don't ask other people to help with it or to learn it in favor of more general and better documented frameworks, though. There are reasons to use standard tools, and there are at times exceptions. There is never an exception without some trade-offs, though.

thanks, good points. this all started because i didnt understand perl well enough to do what i wanted to do, and at the time i didnt know about cpan or perlmonks. so after many months of trial and error this system evolved.

I came to perl monks a few months back and found out a lot, but still none of the existing modules appear to do what i was working on, and it looked like a huge task to learn what to me was a whole new way of doing things. im still struggling with OO, it just wasnt on the syllabus when i did college, and as a result my code looks a lot like the ansi C i was trained to write all them years ago.

Throughout your writeup you are trying to anticipate critical thoughts your readers might have, putting them in their mouth as it were, so as to obviate the need for actually thinking them. The very subject is an example, and it goes on with

cause and effect. on my first foray into the monastary i was after help with some aspects of the system, and got a much less warm welcome than this one.

this time im back just to give away my idea, i dont want anything back, im just a few weeks away from launching a full ecommerce site using this, and i know just how off the wall it is so im presenting as such, an oddity, perhaps if the peer review finally says so, an absurdity... either way these results are much better than last time :)

Your solution doesn't scale. Suppose you've decided to use the first solution

  (case c="(qd)whichfile(/qd)")
    <file1><insertfile>....
    <file2...
  (/case)
[download]

I think you need to find a different way to do this. Even if it means that the parser has to know these few statements as <if>, <case> and <for>.

Or maybe it would be best to parse the file as an ordinary XML and then process it FROM THE ROOT up, always parsing and processing the values of all attributes the same way the whole file is and then if there is a plugin specified for the tag pass both the already processed attributes and not processed content to the plugin and let it decide whether to call the processing for the subtags and then do something with the results or do something with the subtags and then call the recursive processing for the subtags. If there is no plugin, then all the subtags will be processed in order.

I've actually tried to write such a beast ... and found out that I can't write <tag attr="xxx <othertag/> yyy"/> so I decided to change < to { and > to } within the attributes --> <tag attr="xxx {othertag/} yyy"/>. Here's the result:

use strict;
use XML::Rules; # at least 0.20 ! -- I just uploaded that version!

my $parser = XML::Rules->new( rules => [ _default => 'raw extended arr
+ay']);


my %plugins;
%plugins = (
    set => sub {
        die "The <set> plugin requires a name attribute!\n" unless exi
+sts($_[0]->{name});

        my $content = $_[0]->{_content};
        $plugins{$_[0]->{name}} = sub {$content};
        return;
    },
    print => sub {
        print $parser->ToXML( '', process($_[0]->{_content}));
        return;
    },
    select => sub {
        die "The <select> plugin requires a switch attribute!\n" unles
+s exists($_[0]->{switch});

        my $switch = $_[0]->{switch};
        if (exists $_[0]->{':' . $switch}) { # exists a subtag with th
+at name
            return process($_[0]->{':' . $switch}[0]{_content})
        } elsif (exists $_[0]->{':case'}) { # maybe there is a <case i
+d="that name">
            foreach my $case (@{$_[0]->{':case'}}) {
                return process($case->{_content}) if $case->{id} eq $s
+witch;
            }
            return;
        } else {
            return; # the case was not found
        }
    },
);

my $data = $parser->parse( \*DATA);
$data = $data->{_content};

#use Data::Dumper;
#print Dumper($data);
#print Dumper(process($data));
my $result = $parser->ToXML(@{(process($data))->[0]});

print "\n-----------------------------\n\n$result";

sub process {
    my ($what) = @_;
    if (! ref $what) {
        return $what
    } elsif (ref($what) eq 'ARRAY') {
        return [ map {
            if (!ref $_) {
                $_
            } elsif (ref($_) eq 'ARRAY' and @$_ == 2) {
                processAttr($_->[1]);
                if (exists $plugins{$_->[0]}) {
                    $plugins{$_->[0]}->($_->[1])
                } else {
                    $_->[1]{_content} = process($_->[1]{_content});
                    [ $_->[0] => $_->[1]]
                }
            }
        } @$what]
    } else {
        die "process() only accepts strings and array refs.\n";
    }
}

sub processAttr {
    my ($attrs) = @_;
    foreach my $attr (keys %$attrs) {
        next if $attr =~ /^:/;
        next unless $attrs->{$attr} =~ /\{/;
#print "$attrs->{$attr} -> ";
        $attrs->{$attr} =~ tr/{}/<>/;
        my $data = $parser->parse( '<root>' . $attrs->{$attr} . '</roo
+t>');
        $data = $data->{_content}[0][1]{_content};
#print "(" . Dumper($data) . ")";
        $attrs->{$attr} = $parser->ToXML('', process($data));
#print "$attrs->{$attr}\n";
    }
}


__END__
<html>
 <set name="foo">blah blah</set>
 <set name="bar">two</set>
 <set name="x">3</set>
 <h1>I say <foo/>, you know.</h1>
<print>This is printed always!</print>
 <p>
 <select switch="{bar/}">
   <one>This is one.</one>
   <two>This is the other.</two>
   <three>And this is yet another.</three>
   <print>This is NOT printed!</print>
 </select>
 </p>

 <p>
 <select switch="{x/}0">
   <case id="10">This is ten.</case>
   <case id="20">This is twenty.</case>
   <case id="30">This is thirty.</case>
   <case id="41">This is fourty one.<print>This is not printed neither
+!</print></case>
 </select>
 </p>
</html>
[download]

The plugins get as their only parameter a reference to a hash containing the attributes, subtags and content of the tag. There are three kinds of keys in the hash:

• _content = an array ref containing strings and refs to two element arrays containing the name of the subtag and the hash containig its attributes, subtags and content
• :subtagname = an array ref containing the hashes with attributes, subtags and content for all subtags named subtagname
• attributename = the values of the attributes

Not sure it will work for you, but it was an interesting exercise.

thanks for your reply, it was interesting having a look at your solution.

my processor works with the examples I gave and more complex code. within a recursive structure where all the brackets are of the same bracket type my system allows virtually unlimited recursion, however when mixtures of brackets are used, it does as you pointed out have a limitation.

my solution to this, was to make the insertfile routine restart the parser, and thus through multiple files you can indefinitely continue to use the 3 bracket structure. of course with anything very complicated this would become cumbersome having lots of sub files to deal with

as a result i tend to try and be as abstract as possible within the xml-esque control file, and have the plugins do the donkey work. this also leaves the top control file being very close to an english description of what the plugins are doing below, such as <trylogin> or <uploadfile>. Whilst the structure allows for a lot of effects, it wasnt intended to be a scripting language of its own :)

can any of these 3 nest tags inside each other, even within the tag delimiters? ie ;

  <link action="<qd>action</qd>">a link</link>
[download]

because doing tricks like that is a very big part of why i feel the system has merit worth discussion.

While I can't speak to the three templating systems mentioned by anonymonk, I can say that I routinely use constructs such as <a href="<tmpl_var linkdest>">go to <tmpl_var linkdest></a> or <input name="<tmpl_var foo_name>" value="<tmpl_var foo_value>"> with HTML::Template. I would be exceedingly surprised if the others don't also allow such basic templating functionality.

The one caveat with this is that, if the templating tags aren't enclosed in quotes and they look like normal <> HTML tags, then the template will fail to validate as HTML - which is generally fine, so long as the HTML generated from the template is valid. Even so, HTML::Template allows you to use <!--tmpl_var foo--> as an alternative so that the validator will consider it to be a comment rather than a bad tag. (But, then, the same caveat applies to your example with the nested <qd></qd> tags, so I'm not sure why I bothered to mention it...)

well, you may decide you dont want that to always be the *ahem* case :) this way around you have the ability to make that call on a case by case basis.

also the commands listed here are a tiny fraction, i have over 30 plugins already defined which can all be used in a very large number of ways because of the bracket type flexibility.

You mentioned people fuss about the use of three types brackets. I don't find anything bad with that. (Many sucessful templating system use customs brackets.) At worse, you'll have to escape parens and square brackets in your template. (We need to do the latter here at PerlMonks.) What I find to be the insurmountable obstacle is the possibility that a line a screen down might be executed before the line I'm looking at.

You only need a few forms of flow control. No matter how many plugins you have, you'll only have a handful of flow control directives. Too many would just lead to confusion, especially in a template system. Your implication that the number of plugins makes this impractical is nonsense.

Perl uses the concept of keywords (if, for, etc) to control the flow. You could do the same (i.e look for special words like "case".) If you want to extend the flow control to the plugins, you might find the approach taken by Paul Lucas in his HTML-Tree templating system (not to be confused with the HTML::Tree parser). The value returned by the plugin controls whether the body of the tag is skipped or not, and whether the tag is repeated or not. This would actually mesh nicely with your existing syntax.

Even Perl with its millions of plugins (modules) doesn't need to alter precedence in the manner you suggest*. Unless you have have a context-specific grammar (which would be bad for a templating system), there's no reason for this.

* — It has BEGIN, but it's rarely needed. A templating system would not need it.

hrm just checked out that link, it seems similar but i think my idea is more off the wall. also some of their syntax looked pretty confusing, maybe its cause ive been working with my syntax for a while, but it seems clearer to me.