A network of sites, tools, and technology to bring ideas into reality.
The Digital Tumbleweed
Thoughts and ramblings of an enthusiast
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:
To elucidate on your point about Jaxer (I work on the project @ aptana), Jaxer doesn’t require the HTML attribute to be used, in jaxer all javascript functions have a runat/proxy attribute to allow the target to be set dynamically in JS, we have published most samples using the runat attribute as this is the easiest to understand approach.
There really is no limitation in Jaxer to writing unobtrusive code.
@davey
I just want to be sure I’m clear. You’re saying that it’s not necessary to have the “runat” attribute on the script tag? The reason I ask is because I see this on one of the pages (http://www.aptana.com/node/43): “To define and/or execute any code server-side, add a runat attribute to a script block.”
Of course this could be an example and there could be other ways to write the code. Could you provide a link to an example/sample that details the other approaches?
Thanks!
@ncampbell
Read the secton on the page you mention(http://www.aptana.com/node/43) about programmatic runat configuration, the sample code also shows some usage of the function properties.
To be clear at least 1 script needs to be configured to run on the server (as the client has no knowledge of the server capabilities), but that script can then contain all the js code for both client and server, it can load js files as needed and can even dynamically inject script into the dom for serialization to the the client.
@davey
Interesting, so there is no distinction between serverside and clientside functions beyond applying a function variable?
So Jaxer is a post processor between Apache and the users browser? That’s an interesting concept.
There are definitely some large differences between the two as Axiom has a builtin web server.
Thanks for the clarifications!
The power of Jaxer is not what you can do with the server-side features. It lies in combining server-side and client-side code without having to have “glue” code. There’s no need to explicitly perform XMLHTTPRequests, or to code cross-browser differences in how they get done.
I can have some database lookup code in a server-proxied function and call it from the client side whenever I like.
I have some interesting code you might want to see that dynamically adds new comments to a blog post as they are created, while you’re reading the existing comments, and notifies you that there’s new stuff to read. This feature, in Jaxer, is about 50 lines of total code written by me, with the rest (glue code) autogenerated by Jaxer Using it on the client side is as easy as doing .updateComments() from a function that runs on an interval.
In my opinion, the weakness of Jaxer is the focus on the DOM. Axiom can really shine if it comes up with some method of event handler creation that is married to (and as easy to use as) E4X.
@Derik S
I’m curious how you think an event handler married to the e4x functionality would enhance the Axiom Stack and what you would like to see implemented in something like that.
I mean, I’m not entirely sure I understand what you are asking for. You write TALE for your templates. Once those are processed you end up with a DOM. Then you can run e4x on it or any other XML types of data. Are you proposing that Axiom add the ability to attach an attribute such as event=”dofunct()” and then just before it returns the response that event is fired?
Also I curious as to what you see for utility there. I am fairly certain I could write something very similar to what you have with the Axiom Stack, maybe a couple more lines, but not much. Purely because the glitz and glam of the Ajax calls are hidden or because you can write SQL in JS which is processed on the server-side doesn’t appear to be a reason for me to want to go for Jaxer. However, I can see that it allows for less information to be passed back and forth. Fortunately Axiom does allow you to pass back whatever kind of data you are required to.
Thanks for the post, keep em coming!
@deriks
Derik, I’d love to see the code you are using for that jaxer stuff.
I dont understand what you mean by ‘focus on the DOM’
@ncampbell
The main sell for jaxer from my perspective is the single coding environment. no more php/java strings containing js code with horrible escaping to survive the boundary transitions. We are about pushing the dhtml skillset back to the server.
I’m not fundamentalist about this though, i think there is room for many approaches, and good open solutions that meet peoples needs should be available in many flavors, we ca nlearn from the different approaches. A great example of this is pyxer, a Python based ajax server which has taken our approach and allowed python to be the common languauge (although like gwt you’ll still need to dip into js i’d expect to do much of the arcane dynamic browser stuff)
anyway exciting times!
The goal of a lot of frameworks (not Axiom) is to nearly eliminate the amount of client-side Javascript that gets written. Thus you see RJS in Rails controllers and validators and marshalling as supported by Django and Zope 3.
Jaxer also doesn’t limit what kind of data you can pass back and forth. Nothing stops you from doing manual XMLHTTPRequests that support anything from a Jaxer backend to a Microsoft .NET Web Services backend. Except that maybe in the latter case, ASP.NET AJAX (Microsoft’s autogenerator for client-side code) is an easier path!
If you’re comfortable writing client-side Javascript, feel free. But I’m increasingly less so. Everyone who writes significant Javascript code these days is using libraries like JQuery (or Prototype, my personal favorite). Jaxer allows you to use those same libraries on the server side, too.
I used to hold the opinion that any “magic” — such as autogenerating code for the client-side — was evil. I still do, to an extent, but what ASP.NET AJAX and Jaxer generate is so braindead simple that I can live with it. Maybe RJS is like this too.
Axiom is more flexible because it doesn’t dictate how to do your AJAX stuff. But sometimes you’re not looking for flexibility — you’re looking for simplicity. Simplicity bites you in the ass, in my opinion, when you find that the bug that you’ve got to fix is not even in your own code. But that hasn’t happened to me yet with Jaxer. Jaxer is great for rapid prototyping (in conjunction with Firefox and Firebug).
Jaxer makes no sense when building content-driven Web sites that do minimal AJAX.
@ncambell
sorry for turning this thread into a ‘jaxer’ discussion ;-(
@deriks
‘Jaxer makes no sense when building content-driven Web sites that do minimal AJAX.’
I do disagree somewhat with the blank ‘makes no sense’ statement, as it makes lots of sense to me to write all my code in a single language using the tools and environment I have spent time learning (jquery, DOM, even firefox) regardless of AJAX requirements, but I wouldn’t advocate it as being a panacea just yet.
That said, I am really glad you are finding it a useful tool, and would love to see you post something of your experience with it on the Aptana forums. We are trying to be as responsive as possible to developers using the toolset, so any observations you have would be most helpful in improving the product going forward.
cheers