in reply to Re^5: aXML vs TT2
in thread aXML vs TT2

>That wouldn't work

But it does work, I've used this technique before and will be implementing it on the new parser when I get round to it.

Perhaps you had some other case in mind which is different to what I'm thinking?

About the tags, your right giving both standards would be confusing (and processor costly) so I'm only going to be supporting the regular tag types on my version. If anyone using it wants to change it to do both that's entirely upto them.

Replies are listed 'Best First'.
Re^7: aXML vs TT2
by ikegami (Patriarch) on Oct 22, 2011 at 01:08 UTC

    It doesn't work because it can't be used in practice. It renders all "d" inert, not just the ones that aren't aXml directives. It can't be used with your very own example, for one. db_select and d doesn't work in the following:

    <inc title="User Info">header</inc> <no_parse> <table border=0 width="100%"> <tr> <th>User ID</th> <th>Name</th> <th>Email</th> </tr> <db_select> <query> SELECT * FROM user ORDER BY id </query> <mask> <tr> <td><d>id</d></td> <td>[hlink action="user_profile" user_id="<d>id</d>"]<d>name</d> +[/hlink]</td> <td><d>email</d></td> </tr> </mask> </db_select> </table> </no_parse> <inc>footer</inc>

    About the tags, your right giving both standards would be confusing (and processor costly) so I'm only going to be supporting the regular tag types on my version. If anyone using it wants to change it to do both that's entirely upto them.

    What are you talking about? I'm talking about using an attribute instead of a text node for inc, but you keep using plural... Wait, are you saying that aXml requires you to write

    <foo bar="moo"></foo>
    instead of
    <foo bar="moo"/>

    wtf! And because you think it would be less costly to process a whole additional tag? double wtf!

      Ok,first off, <d> is not an aXML tag, it's merely markup used by the <db_select> tag. If you attempted to introduce a separate plugin called "d", you would get errors if you didn't use the precedence operators correctly. Having said that there are plenty of ways of putting bad data into any given parser/compiler and causing errors so that in and of itself is not a valid objection to aXML.

      It is as unreasonable as saying that Perl cannot be any good because you can't call a sub "die" without interfering with the built in function "die". The given set of abstractions which I have built all work together, and can be changed as the programmer wishes, but there is a difference between extending them logically and deliberately causing conflicts between them by giving them names which interfere with each others markup space.

      Secondly, yes the parser as it works right now would require that you write a tag as :

      <foo><bar>moo</bar></foo> or, the preferred; <foo bar="moo"></foo>

      This is a direct consequence of how the parser I have written works rather than any actual necessity of the syntax/language itself.

      A compiler written as Corion suggested would allow for the use of those and of the tag schema your talking about, however as I have already mentioned all attempts I have made to write such a thing have failed miserably and I consider the task "too difficult for me", and more recenly I have come to consider the issue a waste of my time considering the technique is no longer needed for the sake of efficiency thanks to running on top of Plack.

      The current code of the parser is as follows, it is a little rough around the edges at the moment because it is still under development, however it does work and it is fast.

      package aXML::Parser; use Modern::Perl; use aXML::Engine; my ( $aXML,$env,$qd,$session,$cookie,$conf,$dbh,$debug_trace ); sub process { $aXML = $_[0]; $env = $_[1]; $qd = $_[2]; $session = $_[3]; $cookie + = $_[4]; $conf = $_[5]; $dbh = $_[6]; $aXML =~ s@`@<backtick>@g; my $plugins = aXML::Engine::init( $env,$qd,$session,$cookie,$conf,$ +dbh ); $aXML::Engine::scan_more = 1; my $tag_found; while ($aXML::Engine::scan_more) { $aXML::Engine::scan_more = 0; $aXML::Engine::redo = 0; $tag_found = 0; $aXML =~ s@\(([^/\s\)]+)([^\)]*?)\)@ do { if (defined $plugins +->{ $1 }) { $tag_found = 1; +"(`$1$2)" } else { "($1$2)" } } @egs; if ( $tag_found ) { while($aXML =~ s@\(`([^`\s]+)([^`\)]*?)\)([^`]*?)\(/\1\)@ d +o { my $command_args = +aXML::Engine::parse_args( "$1$2" ); my $data = $3; $data =~ s/<null>// +gs; $plugins->{ $comman +d_args->{'tag_name'} }->( $data,$command_args ); } @egs ){} } unless ( $aXML::Engine::redo ) { $tag_found = 0; $aXML =~ s@<([^/\s>]+)([^>]*?)>@ do { if (defined $plugins->{ $1 }) { $tag_found = 1; "<`$1$2>" } else { "<$1$2>" } } @egs; if ( $tag_found ) { while($aXML =~ s@<`([^`\s]+)([^`\>]*?)>([^`]*?)</\1>@ do + { my $command_args = + aXML::Engine::parse_args( "$1$2" ); my $data = $3; $data =~ s/<null>/ +/gs; $plugins->{ $comma +nd_args->{'tag_name'} }->( $data,$command_args ); } @egs ){} } } unless ( $aXML::Engine::redo ) { $tag_found = 0; $aXML =~ s@\[([^/\s\]]+)([^\]]*?)\]@ do { if (defined $plug +ins->{ $1 }) { $tag_found = 1; " +[`$1$2]" } else { "[$1$2]" } } @egs; if ( $tag_found ) { while($aXML =~ s@\[`([^`\s\]]+)([^`\]]*?)\]([^`]*?)\[/\1 +\]@ do { my $command_args + = aXML::Engine::parse_args( "$1$2" ); my $data = $3; $data =~ s/<null +>//gs; $plugins->{ $com +mand_args->{'tag_name'} }->( $data,$command_args ); } @egs ){} } } } $aXML =~ s@`@@gs; $aXML =~ s@<backtick>@`@gs; $aXML =~ s@<null>@@gs; return "$aXML $debug_trace" if $debug_trace; return $aXML; } 1;

        It is as unreasonable as saying that Perl cannot be any good because you can't call a sub "die"

        Actually, Perl does allow you to create a sub named die, and it provides a method of calling the real die if you override die.

        A better example would be string literals. aXML is a like a Perl that's doesn't allow strings that contains «"» to be constructed. It is most definitely reasonable to be able to construct a string that contains «"». That's why Perl provides an escape character and the ability to change delimiters.

        aXML does not have the equivalent of an escape character; it cannot distinguish code from data. That's really really really really really really bad.

        Secondly, yes the parser as it works right now would require that you write a tag as <foo><bar>moo</bar></foo> or ...

        uh, no, «<foo bar="moo"></foo>» is not equivalent to «<foo><bar>moo</bar></foo>». If aXML transforms one in tho the other, it's yet another major problem with aXML.