good chemistry is complicated, and a little bit messy -LW |
|
PerlMonks |
Re^18: Is an aXML compiler possible?by Logicus (Initiate) |
on Oct 31, 2011 at 13:58 UTC ( [id://934882]=note: print w/replies, xml ) | Need Help?? |
Oh what, because part of the post process converts that sequence to a "<"? I already mentioned the possibility of post-inclusion to cover that. (As in an include which occurs after the main processing of the document is done). Let's make the problem harder, and then solve it shall we? Take an exceptional case where, the requirement is to extract information from the database which contains specials, for instance a database containing plugin code which uses them for whatever reason. (very few plugins do btw) In the finest tradition of Perl, we want our baby-aXMLers to be able to do this by writing a simple sequence, supported by code written by a master-aXML/perler if needed. So our baby aXMLer writes this:
Then realises that the output he is getting is not quite the same as what is stored in the database, because the code in the database contains examples of the specials which get converted to brackets at the end of processing. So he hits the manuals or logs into a site such as this one or PerlNights.com, and asks what he can do about it. A kind friendly soul who understands aXML and Perl then offers him a solution; Add a plugin called something like "present_code", which is used like so:
With the source of present_code looking something like this:
Then instructs him to make 6 files in his common files dir of his site which each contain their corresponding special char I.E: lab.aXML contains "&lab;" and so on. The baby aXMLer runs the above code with the new plugin generously coded at obvious labourious length by the master, and finds now he's getting the output he wants. I've also been thinking about how to make extending the system safer, and the thought occurs that it would not be difficult to create an equivalent of warnings for aXML for instance in the extension module:
which when run will cause the following warnings to spit out :
The warnings would need to know all the available HTML tags and the standard set of aXML tags including their reserved markup. It could just have a list of things to look for. User defined extensions wouldn't be covered, but by the time people need to write their own extensions they can probably figure it out for themselves, and we could always have an archive like CPAN for extensions categorised by function. And a mechanism to install them and update the datafile which the warnings package refers to when inspecting the code.
In Section
Seekers of Perl Wisdom
|
|