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

I've done nothing but help fix the very broken aspects of aXML

I appreciate your attempts to help, however you have not actually caused any change in aXML at all so far other than the inclusion of two new special chars which I've never needed and I've included merely so you can bend the way it's used to suit you. aXML is NOT broken, it works perfectly well as it is doing what it does.

On the subject of the compilers, I told Corion about 3 months ago that I believed aXML could not be compiled, he insisted it could, now your telling me it cannot, one of the 3 of us must be wrong.

As for performance I only care about that in so far as it matters to keeping my server bill under control. I am fully aware after having played with aXML on some IBM big iron, that the processing overhead for it is infact miniscule compared to the vast amounts of processing power available if you have enough money to pay for it.

I don't care how it performs relative to any other language / template system. It is what it is, it works the way it works. Clearly you don't like the way it works and that's why your trying to "fix" it when it is not broken.

Your efforts are appreciated, if however misguided.

Replies are listed 'Best First'.
Re^35: aXML vs TT2
by ikegami (Patriarch) on Oct 24, 2011 at 00:40 UTC

    I'm confused. Were my efforts misguided and cause no change, or did you add the special chars?

    On the subject of the compilers, I told Corion about 3 months ago that I believed aXML could not be compiled, he insisted it could, now your telling me it cannot, one of the 3 of us must be wrong.

    Well, the template can be compiled. The problem is that the plugins all return template code, and those can't be compiled, and that's where the real slow down is.

    I'm sure Corion didn't know that your plugins all returned template code.

    it works perfectly well as it is doing what it does.

    You're wrong. You know you're wrong because you're just tried to fix the problem in response to this thread. It may work perfectly well at what *you use it for*, but the only way that can be true is if you use a tiny subset of the functionality you make very clear that it has (the ability to output any format). So in other words, the fact that you've used it successfully is completely irrelevant.

    If it works perfectly well, the answer to Re^33: aXML vs TT2 should be trivial. Please answer it.

[reply]

      I want to start by saying your efforts are very much appreciated, whether they ultimately turn out to be fruitful or not.

      Yes, you have caused the addition of 2 extra lines of code, and a standardisation of the now 6 specials.

      But, no, I've never needed these things before and they seem to be a symptom of having to deal with non-aXML compliant code and it's related issues rather than anything actually wrong with aXML itself.

      Yes, Corion said that the return values should also be compiled as well, which is where I lost him because I can't think of anyway to know ahead of time what a given tag is going to return. Hence I'm with you on your side of that debate, and I have a feeling that following Corion's suggestion to write a compiler for it may of been a wild goose chase and a waste of about 2 months worth of programming time on my part.

      However, having said that somehow Perl does manage to execute the aXML code correctly so it must be compiling it in some manner prior to doing that.

[reply]

        However, having said that somehow Perl does manage to execute the aXML code correctly so it must be compiling it in some manner prior to doing that.

        Perl does not execute any aXML code at all. It executes the code of your parser and plugins. Your parser interprets the aXML code.

[reply]

In Section Meditations