Not quite Perl, but related..

Someone suggested I spend more time defining what my whacky idea is, and while this post is not about perl the implementation to support it is in perl.

aXML ( abstraction XML )

An extensible markup language for defining the interactions of blocks of code to generate any given output.

When I first started building CGI applications, I used the usual suspect modules and built custom code to output the pages required. I found this tiresome, and tried to think up a better way to approach the problem. Back when I was in college I was really into doing 3d graphics, the old rotating cube in 320*200 dos mode ... hey it was 1996!

Anyway that old cube algorythm gave me the idea for how I now build webpages;

The main loop of the cube, would take variables from an array, perform mathmatics upon them, then output the result.

The aXML parser, takes input from various xml files, performs manipulations on them and outputs the result.

In a way, the aXML parser renders 1 frame at a time in a much more convuluted way than the cube program did, and given a specific input, it can produce any output.

The power of the abstraction rests in the document and the way in which im working with it. I'm not simply reading it into memory, or I would use XML::simple

The tags themselves are the code. The aXML document causes the parser to build the output. Tags within the document trigger pre-built perl modules. The result of which is then pasted back into the document.

The simplest possible plugin would take the form $result = $data; let us say this plugin was saved under the name of donothing.aXMLpi

In an aXML document one could then include a tag called <donothing>some data</donothing> and the end HTML document would read "some data".

Typically the parser scans for the tags and runs them from the inner most tags outwards, meaning the result of a tag running can be handed to its parent tag which then runs with that value as its data.

<insertfile><qd>filename</qd></insertfile>

This allows for a complex set of interations to be built up using only the tags in the document. If one has a sufficient number of prebuilt plugin files then one can build complex applications without touching either the parser or the plugins.

Alsorts of neat tricks become possible using this paradym, data and code merge somewhat into a single layer of abstraction.

Finally, this software WORKS, my implementation is rough, my perl knowledge is somewhat lacking as many have gleefully pointed out, BUT, having built a whole CMS using this method I can honestly say, I am commited to continuing this line of development for all my web-projects and it would be really cool if others would; a) help improove the security of the code b) help improove the poetry and performance of the code c) help build new plugins for it

I appreciate that without having used aXML it can be hard to understand why I'm banging on about it, but please can't someone put aside the cynicism for just long enough to get a proper understanding of what im trying to do? Even if its to tell me where I can get a much better more evolved version of the same thing.

Comment on Not quite Perl, but related..

Replies are listed 'Best First'.
Re: Not quite Perl, but related.. by Corion (Patriarch) on Apr 13, 2007 at 07:05 UTC
I think what you describe is basically that aXML is a templating module. Writing your own templating module is some kind of rite of passage in the Perl community - almost everybody at one time wrote their own templating system. In so far there is nothing wrong with you writing your own templating system. I think what would help most people here to judge the value of aXML over the other templating systems is where its advantages and disadvantages lie, compared to the other templating systems. The four major templating systems/languages used in Perl are: Template Toolkit - it has its own language and can be used to create any kind of output, be it XML, HTML or plain text HTML::Template - it has no language and can mostly be used to generate XML/HTML Petal - this is a Perl implementation of the TAL language. It can only create XML and requires its input files to be valid XML too XSLT - this is the most ugly of templating languages because like Petal it requires its input and output to be valid XML but it lacks many of the shortcuts that Petal provides. The most likely XSLT processor in Perl is XML::LibXSLT. Of course, comparing your module requires you to learn a bit about all the existing solutions, but it is no fault to know more than one tool for a task, because all tools differ in some points.	[reply]
Re: Not quite Perl, but related.. by dragonchild (Archbishop) on Apr 13, 2007 at 13:58 UTC
You may want to take a look at Catalyst, CGI::Application, or Bricolage (listed in order of my familiarity and personal recommendation). If you're willing to look at other languages, Rails (for Ruby) and Seaside (for Smalltalk) are both also very good solutions to the problem of generating Yet Another Web Platform. As for driving your webapp using configuration files (which is, essentially, what you're talking about), you might want to look at the MVC and REST architectures (not mutually exclusive). There are a number of good articles on Perlmonks, but wikipedia, perl.com, onlamp.com, and dozens of other sites are great resources, too. Please remember that you're working in a problemspace that has been very well explored for over a decade by some of the brightest minds of our time. This doesn't mean you cannot find a new solution. It just means that it's very unlikely that you will do so. Because of the low probability, you have a higher burden of proof. That includes having learned the current methods so that you know what they are first. If you don't know the current state, how can you improve on it? As for it working - I don't doubt that. But, please bear in mind my signature. And, the second criterion isn't just for the code - it's also for the people using the application. How easy would it be for them to make changes assuming they don't want to know XML? My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re: Not quite Perl, but related.. by duff (Parson) on Apr 13, 2007 at 13:21 UTC
What you describe kind of sounds like axkit, or at least an axkit application. duff	[reply]
Re: Not quite Perl, but related.. by TGI (Parson) on Apr 14, 2007 at 00:48 UTC
As others have said, aXML sounds a lot like YA templating system. On that note, check out HTML::Mason. The main reason I'm writing is to encourage you to keep working, exploring and learning. Corion is right when he says that writing a templating system is right of passage. I wrote a crappy system within a few weeks of starting to code perl. It's such an easy thing to do, it's such a common need. Fortunately for me I wrote mine when I was still baby talking perl and when I discovered CPAN, my code was so obviously inferior it was easy to justify the move to better tools. Take the time to investigate the similar tools that are available. Read their docs, learn to use them, experiment and read the source. If you find one that meets your needs and design philosophy use it, and do what you can to help it get even better. If you don't find something that floats your boat, all that work will give you an excellent experience that you can draw on while building your own system. So don't get discouraged. Please take our advice and comments as an invitation to further exploration and learning. TGI says moo	[reply]