Re^7: Thanks to Ikegami, Chromatic & Corion

[Logicus]

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