A network of sites, tools, and technology to bring ideas into reality.
The Digital Tumbleweed
Thoughts and ramblings of an enthusiast
Axiom Stack is Open Sourced!
While on my way to the 1223 event with a friend, Periodic Design, this week I received a text message, “Stack = open source!” Yes, I’m talking about the Axiom Stack. And my friend can attest, I was _not_ quiet about it. I made sure to confirm it with a few additional sources. While I’m unsure of the exact reasons for open sourcing this product I can tell you some of the benefits, and hopefully I don’t sound like a broken record for the OSS community.
OSS provides a number of benefits to the community. I have recently been using Django a bit for some side projects outside of work. One of the biggest sellers for me was that I had a huge wealth of knowledge already at my disposal. It wasn’t the community and it wasn’t the documentation. It was the ability to dive right into the code and really see what was going on. This is now possible with the Axiom Stack which is _great_. I now have the ability to see the “Axiom” way of doing things by having access to the full codebase. I can also look into issues within the stack code to see whether the problem with my app exist there or in my own source.
Also, now that the source is opened. It is easier for me to make modifications and enhancements to the source. This means that if I feel there are areas which I can enhance, then I have the power to. I don’t have to wait for an enchancement ticket to be pushed into the queue. Now, don’t get me wrong, I think that the engineers working for Axiom Software, Inc are incredibly bright people, much moreso than myself, but in the offchance that I see something that needs some polish, I can do that as well and shoot the patch file back over to those guys. This means that they get time spent on the project that they may not have otherwise normally received.
So, going beyond the benefits of Open Source and looking at the stack itself, I think this is a great move. The Axiom Stack itself is a great web platform. It is extremely easy to develop with and holds a lot of possibility. I’ve used it in developing client sites and on a couple personal projects with another in the works. The Axiom Stack will certainly benefit from this news, however I have a feeling that the benefit will not be solely to the stack but to the community as well.
Axiom Stack: The Personal Edition, Launched
With the multitude of web frameworks out there, picking a good one can be very tough. Hopefully I can help you pick the Axiom Stack. You wont go wrong with that choice. You can find it at: http://www.axiomstack.com. I would highly recommend checking the site out and reading through their documentation. It will help you understand things that I’m going to skip here. I’m not writing a tutorial, yet, just outlining the features. 
The Backend/Database Layer
Axiom natively runs on Lucene. What does this mean for you? You have built-in search. Instead of being required to write sql and logic to get resulting data, you pass in the fields you want to search and the term you want to look for. The Axiom guys have also enhanced the Filtering system too. Now, the thing thats keen about this is that they realized that people currently know RDB’s. So, they have the built-in ability to use a relational database straight through the stack assuming there is a JDBC driver for your database. Also, you can utilize the power of both systems at the same time. You can have objects built that are Lucene based, and objects that are RDM based. It’s extremely handy when you have data already stored in other databases that you really would prefer not to migrate (migrating content is a pain…I know first hand).
So, you get some nice data storage services right off the bat.
The Middle Tier/Logic Layer
This layer is by far the most interesting, only because there is so much going on here. You have the ability to write Javascript on the server-side. Thats right I said it, Javascript on the server-side. Fundamentally, all you have to do is create a JS file, dump that into a folder and BAM, you have server-side logic.
The way this works really works is through prototypes. Javascript has a funky way of representing objects. The way it works is through prototypes and the same notion is used here. To create a concrete understanding of the separation you first create a directory in your application. That directory now defines your prototype. The next step is to create a mapping of the properties. This mapping tells the Axiom backend code how to set the datastores up. Then you create a JS file or a few. The JS files are loaded together, so be sure you keep your naming as accurate as possible such that you don’t clobber other functions. If you think about it, if you write a function called getMe inside your prototype definition, and then later do something to the effect of o.getMe = function() {}, you’ve overwritten the original function. So just be careful about naming. I tend to break my functions up by files such that the functions in a JS file all do similar things such as rendering to the screen, macros that happen all the time, etc. The only function you need to be absolutely concerned with is the main method. This is the function that is called by default when you request and object.
It’s extremely easy to create objects in Axiom. You don’t have to do much. Now, if you really want to enhance the functionality you have a great many things you can do. Not only is e4x available (with full xpath support), but all the features of Rhino. This includes list comprehensions, WOOT!! I’ve loved using list comprehensions in python and the fact that I can use them in my Axiom code, even better! So, beyond this there is the whole LiveConnect thing. LiveConnect enables direct access to Java classes and methods through the Javascript. So, if you are finding that the Javascript really isn’t suitable for what you need, or that there is a library out there that already does what you need, you can use the Java code to make it happen. It’s pretty sweet. I’ve dabbled with it and use it for a number of things.
Now, you may have heard of Aptana’s Jaxer server allowing you to write javascript on the server-side while having full DOM capabilities and such forth. But, what you have to do is write html tags that tell the Jaxer server what to run and what not to run. While alright, it doesn’t lend itself to real extensibility IMO. Why do you want to have to riddle your presentation layer with server-side specific tags and code? What happens if you need to change something? Are you forced to change it in both locations? It doesn’t seem practical to me.
With Axiom, the request comes into the server, the server takes the request. If the request is to an object then the main method is used and then processed. If the request is for a method on that object, then that method is processed. This means that you are processing the methods before the templates giving you a lot of flexibility with the kind of data you want to send out. Now, what is a bit tricky here is that the templates, i haven’t gotten to these yet, are considered to be functions which I’ll get into a bit more later. The reason I bring it up here is to point out that you can, should you want name a template such that you can request it from a URL. So, if you have a very basic template or something that doesn’t need the Javascript processing to display it, just name the template what you were going to name the JS function.
The Front-End/Presentation Layer
The frontend is all about TALE. TALE is a proprietary templating language that was developed by the Axiom people. It’s really very simple and that was their intention. There are a handful of directives you can use, and the directives are quite simply just attributes on XHTML elements. You can think of it like XSL without the suck. What I mean by that is that it is not clunky and overbearing. It doesn’t introduce insane amounts of extraneous code into your template just to get logic to work; remember, the logic is done in the JS. The templates allow you to manipulate the XHTML output based on the data you pass into it. A cool element to TALE is that it natively parses JS. So, you can use simple JS to gain access to your information.
To add the last element to your prototype, you create a template inside the prototype directory. This file is now a template for any objects of that type. So in the template you can use proper scoping such that you get access to an objects methods and properties. “this.someFunc()” will look for the someFunc method on the current object. It does that naturally in Javscript, well, you also have that available in the TALE.
My Thoughts
Axiom is a great tool. It provides a ton of functionality and some awesome features that you wont find elsewhere. You’ve got a number of create technologies that have been used with it. And, if you find that you’re missing something, you can write a Java lib or use one to enhance your experience. Really, this does up the ante for other web frameworks out there. It raises the bar. I highly recommend using Axiom as your platform. While the community right now is fairly small, it is active and the people involved are highly knowledgeable about it. Check below for some extra links for good reading.
Some extra links:
