Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re^2: aXML vs TT2

by Logicus
on Oct 21, 2011 at 18:56 UTC ( #932963=note: print w/replies, xml ) Need Help??

in reply to Re: aXML vs TT2
in thread aXML vs TT2

Ok my answer needs to be in two parts.

Firstly, in accordance with the currently defined given set of symbol definitions, db_select is an aXML tag, whilst query is just meta that db_select requires to function but is not defined as an active tag by itself. (it has no code associated with it)

Secondly, if you don't like the given tag definitions you can change them to suit your requirements since they are simply perl subs contained in a hash table. Thus if your application requires that you work with an xml file containing tags which correspond to existing definitions, and you don't want those tags to trigger code functionality in the subs, you can just rename those definitions to something else (or delete them from the table, or overload them with a plugin localised to the given action). It's completely soft-coded and your in complete control of your abstractions.

Replies are listed 'Best First'.
Re^3: aXML vs TT2
by ikegami (Pope) on Oct 21, 2011 at 19:11 UTC

    It's not the worst solution, but it's inherently fragile.

    It requires that I know every element name that can be found in an XML document. Some formats are extensible (e.g. XHTML), so there is no such list for them. And even if we assume that list can be found, most people won't bother trying to create it.

    It requires that I cross check that list against the list of keywords in a hash. How is that possible to do reliably if the list if as dynamic as you say.

    This will lead to errors that can be very subtle. And given how templates are typically used, the errors will not be seen by the dev and they will be seen by end users.

    The thing is, XML has already solved that problem. The mechanism is called "namespaces".

    <root xmlns:a=""> <a:inc title="User Info">header</a:inc> <table border=0 width="100%"> <tr> <th>User ID</th> <th>Name</th> <th>Email</th> </tr> <a:db_select> <a:query> SELECT * FROM user ORDER BY id </a:query> <a:mask> <tr> <td><a:d>id</a:d></td> <td>[hlink action="user_profile" user_id="<a:d>id</a:d>"]<a:d>na +me</a:d>[/hlink]</td> <td><a:d>email</a:d></td> </tr> </a:mask> </a:db_select> </table> <a:inc>footer</a:inc> </root>

    PS — I personally prefer <inc name="header"/> over <inc>header</inc>.

      ...It requires that I know every element name that can be found in an XML document...

      Ok then, we add a new sub called something like <no_parse> which takes a path to the XML to be included in the output. The file is loaded and stored in memory and inserted after the parser has exited. That way it doesn't matter if the file to be included contains tags which match the plugins because it wont be seen by the parser. The original version has something similar to that called <ignore>, but I haven't got round to creating that functionality in the new one yet.

      Oh and regarding shortend tags like <inc name="header"/> I like that, however supporting those sort of tags as well as the standard ones will require extra compute time under the current methodology. It's perfectly possible to do, but I'm not sure the gain would be worth the overhead.

      That's not to say that the current methodology is the be all and end all, Corion once suggested writing a compiler for aXML which would solve that problem and further improve overall performance, however such a solution is currently over my head and given how blazing fast the current version is I just can't feel the desire to try and implement it (again).

        Ok then, we add a new sub called something like <no_parse>

        That wouldn't work.

        Oh and regarding shortend tags like <inc name="header"/>

        It wasn't shortened. It's actually three characters longer. It just seems clearer to me for inc

        however supporting those sort of tags as well as the standard ones

        I wasn't suggesting that you handle both <inc>header</inc> and <inc name="header"/>, just one of them. Supporting both would be confusing.

        So what does your system do right now when it sees a tag like <tag />? Does it get ignored?

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2021-10-21 18:40 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (83 votes). Check out past polls.