Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^6: Thanks to Ikegami, Chromatic & Corion

by ikegami (Pope)
on Nov 02, 2011 at 04:56 UTC ( #935291=note: print w/ replies, xml ) Need Help??


in reply to Re^5: Thanks to Ikegami, Chromatic & Corion
in thread Thanks to Ikegami, Chromatic & Corion

I'm going to add that sub escape in the parser right now

The point of escape is to prevent aXML from processing that which is passed to the function. It is used by plugins, not aXML. aXML performs the *reverse* operation after the template has been fully processed.

my %escapes = ( '&lab;' => '<', '&rab;' => '>', '&lcb;' => '(', '&rcb;' => ')', '&lsb;' => '[', '&rsb;' => ']', ); sub final_processing { my ($content) = @_; $content =~ s{ (?: (&[lr][acs]b;) | <special...>(...)</special> | <post_include...>(...)</post_include> ) }{ if (defined($1)) { $escapes{$1} } elsif (defined($2)) { '&'.$2.';' } else { ... } }xeg; return $content; }


Comment on Re^6: Thanks to Ikegami, Chromatic & Corion
Select or Download Code
Re^7: Thanks to Ikegami, Chromatic & Corion
by Logicus on Nov 02, 2011 at 13:38 UTC

    Huh?

    I have this gut feeling, about which I am by no-means certain, that if you were to build a compiler based on how your currently thinking aXML should work, it would be very fast but would not render certain documents correctly. Specifically documents which contain higher level compound aXML statements.

    The only analogy I can think of right now is if I handed you a Lego Technic kit that you can build a transformer out of, composed of lots of lovely little pieces designed to fit together and to transform smoothly from their initial state to their final state, and you took it to pieces added a few constraints to several of the blocks, and then put it back together again, it would no longer transform correctly.

    Optimus Prime would be a cripple.

    Look I don't know... as I said before I've only begun to scratch the surface of how aXML units can inter-operate and transform themselves and each other from the initial state to the rendered state.

    All I know is that by using the quasi-xml style markup, the transformation is well structured and guided by the structure to perform the same transition smoothly time and time again.

    When I was working with the thing at the start, speed and efficiency were not my primary concerns. The flexibility and expressivity of the language were. I figured that I could solve the efficiency issues later. (which I have now to sufficient degree for my usages)

    Now, thing is right, just because I came up with the schema doesn't mean I know everything about it or that the way I use it is necessarily the ideal way of using it. I recognise that fact and welcome anyone wanting to come up with any sort of variant on it.

    All I can say is that I've found a pattern that works for me, and is the best way to use it that I have been able to conceive of so far.

    Basically in my PSGI file, all documents start out with the same identical seed :

    my $action = sub { return [200, [ 'Content-Type' => 'text/aXML' ], [ '(use)(qd)action(/qd)(/use)' ] ]; };

    This is the same as saying :

    my $action = sub { return [200, [ 'Content-Type' => 'text/aXML' ], [ process( "$doc_root/actions/$qd->{'action'}/body.aXML" ) ] ]; };

    The Plack::Middleware::aXML component takes that seed and from that point the parser iterates over the document as many times as needed transforming it one step at a time into the final result.

    Typically, at least in my code, the body.aXML that is loaded contains a call to include a template, either the public page template or the private page template (for the control panel pages for instance), which then has further processing directives in it. Some of the body.aXML files also contain calls to do some processing prior to loading the template, so that the template will render correctly after something has changed, for instance the user preference for CSS colour scheme.

    If plugins are not able to return valid markup for the parser to pickup on on it's next iteration, the "use" statement would be useless, and processing would halt at that point because the inserted template would not contain any directives the parser can recognise.

    Autobots! Transform! .... *CRUNCH*... er...

      The only analogy I can think of right now is if I handed you a Lego Technic kit that you can build a transformer out of, composed of lots of lovely little pieces designed to fit together and to transform smoothly from their initial state to their final state

      The problem is that the little pieces don't fit together in what you handed me. There are some connectors missing. I'm slowly getting you to realise these connectors are missing.

      would not render certain documents correctly.

      Only if you misapply it.

      Your current flow is:

      plugin produces aXML code, parser takes that aXML code and produces HTML code, browser takes that HTML code and produces text.

      Except your plugins don't always produce aXML code. For example, look at d. IIRC, you said it currently produces HTML. escape addresses that bug. It will convert the HTML into aXML.

      text_to_aXML: The "escape" function I posted, renamed for clarity. text_to_html: Converts & to &amp, < to &lt, etc. # Current sub d { my $text = ...; return text_to_html($text); } # Should be sub d { my $text = ...; return text_to_aXML(text_to_html($text)); }

      You seem to be considering what would happen if every plugin used it, and indeed that would make no sense.

        plugin produces aXML code, parser takes that aXML code and produces HTML code, browser takes that HTML code and produces text.

        You've misunderstood the flow.

        parser takes aXML code, parser discovers/executes valid aXML tags plugins produce either aXML or HTML or mix of both (or other) parser discovers/executes valid aXML tags plugins produce either aXML or HTML or mix of both (or other) .... parser can find no more valid aXML tags parser exits, post processing occurs browser takes finished resulting HTML and produces page

        Here, I just got finished playing around with a question someone posted about processing some poorly formed HTML given that they don't know (or want to know) anything about regexs.

        In aXML I would solve it like this :

        (aXMLplugin name="TD")"$_[0]",(/aXMLplugin) (aXMLplugin name="TR") <db_write>INSERT INTO captured_rows VALUES (<chop><strip_tws>$_[0]</strip_tws></chop>); </db_write> (/aXMLplugin) (inc)path/to/htmldata(/inc)

        The above primes two new plugins called TR and TD just for this job, then includes the html file specified and processes it adding any information it can correctly identify into a database as it goes.

        The states it goes through during processing are:

        State1 ------ (aXMLplugin name="TD")"$_[0]",(/aXMLplugin) (aXMLplugin name="TR") <db_write>INSERT INTO captured_rows VALUES (<chop><strip_tws>$_[0]</strip_tws></chop>); </db_write> (/aXMLplugin) (inc)path/to/htmldata(/inc) State2 ------ (aXMLplugin name="TR") <db_write>INSERT INTO captured_rows VALUES (<chop><strip_tws>$_[0]</strip_tws></chop>); </db_write> (/aXMLplugin) (inc)path/to/htmldata(/inc) State3 ------ (inc)path/to/htmldata(/inc) State4 ------ <TR> <TD> Channel </TD> <TD> Call Letters </TD> <TD> Count </TD> <TD> Percent </TD> <TD> Title </TD> </TR> ... ... State5 ------ <TR> " Channel ", " Call Letters ", " Count ", " Percent ", " Title ", </TR> ... ... State6 ------ <db_write> INSERT INTO captured_rows VALUES (<chop><strip_tws> " Channel ", " Call Letters ", " Percent ", " Title ", </strip_tws></chop>);</db_write> ... ... State7 ------ <db_write> INSERT INTO captured_rows VALUES (<chop> " Channel ", " Call Letters ", " Percent ", " Title ",</chop>);</db_write> ... ... State8 ------ <db_write> INSERT INTO captured_rows VALUES ( " Channel ", " Call Letters ", " Percent ", " Title ");</db_write> ... ...

        As I'm sure you can see there are a couple of plugins there that are not in the standard set I sent to you earlier. I think it should be quite obvious to you how they would work and how you would go about adding them to the set.

        Except maybe the "(aXMLplugin)" tag, which needs a little more explanation... the data it contains is returned interpolated. So:

        (aXMLplugin name="greet")hello world(/aXMLplugin)

        Would look like this in the plugin code it produces :

        greet => sub {"hello world"},

        The fact it's a one liner to be interpolated is taken as being implicit in the way I'm thinking about this plugin at the moment, such that :

        (aXMLplugin name="foo")"hello world"(/aXMLplugin)

        Would look like this in the code level :

        foo => sub {"\"hello world\""},

        And give this for output :

        "hello world"

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://935291]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (17)
As of 2014-12-18 15:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (58 votes), past polls