So it is far from trivial...

Whatever is output from a tag goes back into the document and is treated exactly the same as everything else. The tags input aXML and output aXML, there is no distinction and it's upto the designer how to deal with that. I've found through experience a set of abstractions that exist in harmony with each other and I'll be giving those as a suggested default set because you can build just about anything with them.

When it comes to writing your own plugins, a sound understanding of how the plugins interact and how you intend to use the new plugin and how it relates to other plugins will be needed.

Having said that, it really isn't as hard as it may seem because the rules are very simple. Any programmer worth their salt will be able to master it in a matter of hours or maybe even minutes in some cases.



I would reconsider this design choice...

I wouldn't it works great exactly as it is.



not being able to use aXML to generate XML and aXML

There is no problem with that at all since you have complete control over the plugins their names and definitions.



security holes like user generated content triggering internal aXML code.

I went into this before somewhere. There are basically only two vectors; the query data and the cookies. Putting the cookies aside for a moment as there is little scope for insertion there, the solution I found to this problem was to sanitize the query data prior to starting the document.

What I'm going to do is add a key to the conf hash in the Conf.pm file, that is an array of allowed tags. If anything else exists in the query data it will be converted so that it cannot be recognised by the parser and thus passes through without the possibility of effecting anything else. I'm making the list an allowed list instead of a disallowed list so if the list is empty it will not allow any tags through at all.



proper documentation

Gotta finish writing the thing first!! The new version is almost ready just got a few rough edges to sort out, some more plugins to port from the old version and then it should be just about ready to rock.



& < etc

In the vast majority of cases an aXML programmer won't actually need to worry about that stuff at all, they are rare special case features which "close the circle" so to speak. Understanding them will only be required if you have an application which can't live without them, for instance feeding very specific XML data to another system which will throw exceptions unless special chars are encoded right.

In reply to Re^30: aXML vs TT2 by Logicus
in thread aXML vs TT2 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.