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)'  ] ]; };

[download]

This is the same as saying :


my $action = sub {
     
return [200, [ 'Content-Type' => 'text/aXML' ],

       [ 
         process(

          "$doc_root/actions/$qd->{'action'}/body.aXML" 

                ) 
       ] 
    ]; 
};

[download]

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...

In reply to Re^7: Thanks to Ikegami, Chromatic & Corion by Logicus
in thread Thanks to Ikegami, Chromatic & Corion by Logicus

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.