http://www.perlmonks.org?node_id=932789


in reply to Re^7: Plack Middleware aXML
in thread Plack Middleware aXML

There's no way to reimplement your example as there's no way to understand what the heck is the magic incantation supposed to do. On the other hand if instead of aXML "plugins" you simply implemented the same number of functions I'm pretty sure you could call them by code that'd be about as long, if not shorter, as your aXML example.

See ... you do not have to write all your code using the modules you got with Perl or downloaded from CPAN. You can write your own, more specialized and higher level modules and then ... instead of using Plack::Request and DBI directly, you just call the functions or methods from those modules.

If instead of fiddling with the aXML engine and writing aXML plugins, you wrote prettymuch the same thing you've put into the plugins as a plain old module, you could write Perl code at exactly the same level of abstraction.

And then the way to add the AJAX chat you boast about in your later post would be

AJAXchat("path/to/storefile");

If you want a fair comparison at least for the simplistic "dump if debugging" example include in your SLOC the definitions of the debug and dump aXML plugins and then compare that with my code. Or compare your (debug)<dump>$env->{'psgix.session'}</dump>(/debug) with it's pure Perl counterpart debug { Dump($env->{'psgix.session'}) };.

Jenda
Enoch was right!
Enjoy the last years of Rome.

Replies are listed 'Best First'.
Re^9: Plack Middleware aXML
by Logicus (Initiate) on Oct 21, 2011 at 02:17 UTC

    Look Jenda-dude, your not telling me anything I don't already know here, and comparing aXML with Perl itself is not a fair or valid comparison. I know I started it, but only as a means to try and introduce a new thing which works in a completely different way, by relating it to concepts of which your already aware.

    A fairer comparison perhaps would be comparing aXML with something like TT2, however once again this is comparing apples and oranges, since TT2 has a limited domain-specific language for controlling document layouts, where aXML has a simple an open ended syntax which by virtue of that fact tha t definition files are coded in perl, is turing complete and far more expressive.

    I understand that it's difficult to see what I'm saying clearly using only what I have typed up for reference because I'm struggling to find ways to effectively communicate the concept. That's not entirely my fault either because aXML is not like anything else that I have ever come across and the comparisons usually fail to clearly express the situation properly.

    aXML has no conditionals, variables, loops or operators, all it concerns itself with is abstract symbols and their correct processing order. From the very simple ruleset you can derive huge complexity in very neat, understandable and reusable code.

    Now sure, you could obfuscate the hell out of it...

    (j34) <hhrhe>gghheh</hhrhe> <fdkes>adalekaeka</fdkes> <asdj3> [sdf] <sdkjer>aksdjke</sdkjer> [/sdf] </asdj3> (/j34)

    The above represents a VALID aXML expression, which aXML can process, given a plugin set which corresponds to the symbols. What does it do? there is no way to know however you can infer that :

    • j34 is the first plugin to be run
    • j34 takes 3 arguments
    • sdf is passed through, and is computed last. Indeed it's probably replicated by a loop inside the code of j34

    To know what the above does you have to know what the plugins do, which is why I recommend using descriptive tag names rather than obfuscated ones, but that's really upto you, there is no limitation on what you call your symbols or what they do. The symbols can even modify each other and the document as a whole at runtime, a feature I have exploited in previous projects.

    To give another example, consider this:

    (case c="(qd)foo(/qd)") <bar> [inc]bar[/inc] </bar> <baz> [inc]baz[/inc] </baz> (/case)

    The above has exactly the same result as :

    <inc>(qd)foo(/qd)</inc> or (inc)(qd)foo(/qd)(/inc) or [inc][qd]... or [inc](qd)... or <inc>(qd)...

    However you might want to use the case statement instead if you want to catch an error such as qd->foo containing a value which links to a file which doesn't exist..

    (case c="(qd)foo(/qd)") <bar> [inc]bar[/inc] </bar> <baz> [inc]baz[/inc] </baz> <else> [inc]wtf[/inc] </else> (/case)

    This would be the same as saying :

    given ($foo) { when (/bar/) { return get_file('bar'); } when (/baz/) { return get_file('baz'); } default { return get_file('wtf'); } }

    Again there is always a mapping, but sometimes it's hard to see what that mapping would be for instance;

    <case c="(qd)foo(/qd)"> (inc)cases(/inc) </case>

    Where the file "cases" contains the code which was previously in the case tag, but now is added in dynamically prior to the case tag executing. The result is the same, however I cannot imagine how you could do that normally (that's not to say you can't, just that it probably requires a higher level of perl mastery than I currently have, and definitely a higher level of mastery than is needed to achieve the same result quickly and easily in aXML.