(first posted: Dec 31, 2006)
(2266 Reads)
keywords: ruby on rails xaraya
Permalink
Ruby-on-Rails versus Xaraya
Starting Out Cynical
"Ruby on Rails", might as well be called "Hype on Steroids". OK, sure it's reported to be the greatest thing for web development since sliced bread, javascript, and crack cocaine. And everyone's doing it, or so it seems. i even read that Apple is planning to include it standard on the next release of OSX.
The first time I watched its "amazing video demo" was over 2 years ago (October 2004) when I was researching a framework to learn and use for my upcoming projects. It seemed so cool, and probably still is. Seriously. But I was turned off by the hype, even back then. Plus, Ruby is a whole new programming language, so unfamiliar to me.
So I settled on PhP as my language of choice. It is much closer to my previous life of programming in C/C++, and I just didn't get excited by other web languages like Perl and Python.
And I concentrated my efforts and dedicated myself to Xaraya as my web framework / CMS (content management system). That decision has been very good to me, I've implemented some major web projects (and many minor ones too) with Xaraya, and I'm continually impressed with its power, flexibility, and transparency.
My major concerns about Xaraya include the difficulties in debugging my projects (translates into wasted time), its dependency on a very small group of developers, and that the project (recently) appears to lack momentum (at least in "internet time").
Meanwhile the RoR hype hasn't let up. It has a very strong following, both in the corporate world as well as the open source communities. After all, there are books written about it; you can't say that for Xaraya. Or put another way, if you had a company and were looking for investors, and you told them the product is built with Rails, they'd say "Oh, Wow!", whereas if you say it's built with Xaraya, they'd say "oh, what's that?"... Is that fair? Probably not. But so much in life is about impressions.
So, there's some good reasons to kick the tires on RoR and compare it with my current tools of choice.
In General
First of all, is this even a fair comparison? Perhaps not exactly "apples" and "oranges" but close enough. At a minimum, when starting a new web application one must make a decision what platform to use, whether it be Xaraya, RoR, .NET, etc.
Let's consider that Xaraya is a web framework (the Xaraya "core"), written in the PhP language, with a body of additional components (e.g. functional "modules" and templated "themes"). RoR also is a web framework (Rails), written in the Ruby language, with a body of additional components (plug-ins). Both are free, open source projects.
Here's a summary comparison of some of the attributes of each project:
| FEATURE |
XARAYA 1.1.3 | RAILS 1.2 |
| Language | Php | Ruby |
| Paradigm | MVC | MVC |
| Framework | Xaraya | Rails |
| Recommended Web server |
apache, lighttp, or any |
lighttp, webrick, apache, or any |
| Database abstraction |
adodb |
ruby adaptors |
| Data schema tools |
dynamicData module | migrate class |
| testing tools |
n/a |
yes |
| Devel vs production databases |
(manual) |
yes |
| Website | http://www.xaraya.com/ | http://www.rubyonrails.org/ |
I won't attempt to explain Rails or Xaraya in much depth here (nor Ruby or PhP), there are plenty of tutorials elsewhere.
Much of my information about Rails has come from reading the first 200 pages of the book "Agile Web Development with Rails, Second Edition " (available in hardcopy or PDF). Plus a couple other articles/tutorials I walked through.
Language
Ruby is unlike any language I've used, and I've used some pretty weird languages (ever heard of "PL/1"? that was cool stuff). When I was in graduate school at MIT in the 1980's, a computer scientist asked me what language I was programming my thesis project, I told him "C". He had vaguely heard of it (MIT was the bastion of the LISP language), "Oh" he said, "is that a stack-oriented language?" Heh! But I digress...
Even weirder is the Ruby tutorial document promoted on the RoR web site, "Why's (Poignant) Guide to Ruby". I think the guy (whose name is "Why") is certifiably insane. Perhaps too much ecstasy or mushrooms. Is this a reflection of the makeup of the RoR community?! Actually I read almost every paragraph, it really was a fun read and I learned a thing or two along the way.
Ruby is a rich object-oriented language, with a very compact syntax. My impression is that the learning curve will be steep, but once you really get your arms around it (including many of the built in and library features) it could really be powerful and extremely efficient.
Xaraya 1.x is built on Php 4 and is incrementally making the transition to object orientation (the current code has both procedural and object layers, just not consistently nor everywhere). Xaraya 2x promises to be more object oriented. and will require PhP 5, which has added much better object support. Even so, PhP still strikes me as primarily a procedural language trying to play catch up.
As far as I can tell, the only reason to learn and use Ruby is for Rails. And the body of Ruby packages are most likely being developed by RoR developers. Maybe that's a good thing. Maybe it's not.
PhP on the other hand is a very well established language with a plethora of open source (and proprietary) projects and applications. This means you have more choices for best of breed libraries, apps, and tools to integrate with your Xaraya application. And there's a lot more PhP programmers out there if you need to subcontract one.
MVC Paradigm
Both Rails and Xaraya are based on the Model-View-Controller (MVC) paradigm. Briefly this means you have a database "model" (schema) and code that manages it (your "business logic"); you have "view" templates that present model data to the user (e.g. generated html web pages); and "controller" code that takes user input (e.g a click on a web link) and directs it to a processing function (who interacts with the model and presents an updated view back to the user).
One big difference seems to be that Rails has you start by designing your database schema, and then you build the code (classes) to manage the logic and the templates (views) to display it.
In Xaraya you tend to start by installing the functional modules you want to use (which sets up a default db schema), and then you modify the data fields using admin configuration options and hooks (especially dynamicdata hooks), and the templates (theme) to display it.
Framework
Both Rails and Xaraya have established their own standard conventions for naming functions, files, and the directory structure where files are maintained on the server.
Consider the (default) interpretation of short URL's in each framework:
Xaraya: http://www.mysite.com/mod/func/id
Rails: http://www.mysite.com/contr/action/id
Module/Controller
In Xaraya, "mod" is the module that generates the main content. "func" is the name of the function to call, which would literally be mod_user_func() in file modules/mod/xaruser/func.php.
In Rails, the "contr" is the controller class, and "action" is the method. The class name would actually be ContrController in the file app/controllers/contr_controller.rb
"id" is the item or record identifier.
Note, both platforms let you alter the default structure and interpretation of url parameters, more or less.
Template/View
In Xaraya, the template used would be modules/mod/xartemplates/user-func.xd (or override themes/mytheme/modules/mod/user-func.xt). The page layout would come from themes/mytheme/pages/default.xt (or if present, themes/mytheme/pages/mod.xt).
In Rails, the template used would be app/views/contr/action.rhtml. The page layout might come from apps/layouts/contr.rhtml
Tables/Model
In Xaraya a module maintains its own set of database tables, by convention named something like xar_mod. Accessing these tables are pretty much buried from view from the user (web developer) accessed via module user or admin functions, or through the module's API functions.
In Rails you have more direct control over the database; and the (default) class code is automatically generated for you. As mentioned above, in Rails you tend to start your development by defining the database schema.
So lets say you create a db table "products", Rails will automatically use a controller class ProductController (notice it handles the singular/pluralization too :), which understands the table columns from the database, and automatically makes available to you functions for managing and displaying rows in the table (e.g. the CRUD functions - create, read, update, delete).
This auto-generated functional support is called "scaffolding" in Rails. It provides rich yet basic support for your db tables. The generated files work but are not intended for production. You replace them, incrementally, as your app develops. Just like scaffolding on a building, they're there while you build the walls, then come down as as the actual building stands on its own. This is one reason Rails lends itself to rapid and agile development.
Another point. Xaraya is moving toward its core "dynamicData" (DD) module for interfacing your app (and new modules) with the database storage. DD has a rich set of features and tools, not the least of which are extendable dynamic property types and validations. The default storage of DD is rather inefficient, using a separate table row for each field. However you can make dedicated tables for your DD objects, and even define foreign keys and such. (I'm still somewhat timid to use them as I should).
Rails also has comprehensive support for validations and error handling. Perhaps even more intuitive than Xaraya's. I'm just not sure they're as well organized.
Web Server
Not much to say here except, in general, it seems the RoR team has stronger recommendations and support for your development and deployment environments. The Xaraya teams pretty much leaves this up to you. Everyone seems to like LigHTTP (lighty).
With regard to scalablity and/or deployment in an enterprise environment, I'm not sure what to say. My understanding is that both systems are equally capable of supporting multi-box configurations (e.g. your database is on a separate machine from the http server). Both seem to have very good and flexible cacheing support available. In reality, I've read that there are some large RoR based sites deployed, and I'm not aware of any large Xaraya-based site in production.
Database Abstraction and Tools
I touched on this above so I wont repeat myself. But I do have a few things to add.
Xaraya uses the ADODB library to abstract its interface with the native SQL database. Rails has its own adaptors written in Ruby, running on a database engine. 6 of one, half dozen of the other as far as I'm concerned.
Xaraya's very cool DynamicData utilties are like a built-in phpMyAdmin that knows inherently the underlying Xaraya db schema.
One problem I have with Xaraya development is when I'm setup with a development site (typically on my local LAN, though not always) and a production site (on the Web). When I change things in the Xaraya theme templates, those are very easy to deploy to the production site. But when I change things in the database, I have to be careful to remember what I changed, then make the equivalent parallel changes on the production site. And test well, because I can screw up. (The alternative approach is to lock down the production site, copy its db to my local environment, do my development and testing, then copy it back. Sometimes I do that, but usually it's not feasible).
Rails automatically maintains separate database for development and production.
Rails has tools for migrating your database structure changes, called "migration". You specify changes to a table's layout in a migration file (using .yml format), and run the migration script. You can then roll back changes. Or propagate them to other databases (eg from development to production). Note, I haven't used this or even read enough to know how well it preserved the data contained in the tables that you've restructured, or what tools might be available to facilitate this. It's important though that the framework for development vs production is built in.
Testing Tools
Here's an area that Rails seems unique in general. Rails has testing built into the framework. Rails calls things that test models "unit tests", things that test a single action in a controller "functional tests", and things that test the flow through one or more controllers "integration tests". These .rb files are kept in directories test/unit/, test/functional, and test/integration, respectively.
Rails also maintains a database just for tests, so you can setup a reusable known set of test cases. You can even script out domain-specific high level test scenarios, like multiple sessions of users each adding products to your shopping cart and checking out...
What Else?
I know I've just barely scratched the surface. I'm just getting my feet web with Ruby on Rails whereas I have years of experience with Xaraya and know it well.
Xaraya has dozens of modules, each neatly orthogonal (minimal overlap in features), that can be hooked together with just a few clicks. Xaraya also has user-contributed themes that help get people going quickly.
What else? Lots.
Xaraya's templating language, Block Layout, is fully XML compliant and extendable as developers can add new tags (.xt files). Rails lets you embed native Ruby code in its templates (.rhtml files).
Xaraya has blocks and subtemplates (xar:template tag). Rails has "partials".
Xaraya has very strong security, authentication, and privileges built-in. The tutorials I read for Rails show how to easily roll your own, with access to sessions, a login model, and data filters. I'm sure there's downloadable plug-ins for these, I just haven't gotten there yet.
Xaraya has lots of other nice tools, like a module for the TinyMCE (wysiwyg editor widget), support for RSS and RPC and other services, etc etc. I'm sure Rails does too.
I know the Rails community is big, so I have a lot of exploring to do to see what's out there, and how good it is.
In fact, this might be a problem in itself. Xaraya is a small community, and while may not have enough pieces for all the functionality you need, you can get a clear picture of the pieces it does have. My fear with a big project like Rails is the risk of a large amount of junk out there, how much you're expected to write on your own, and what it takes for me to have the knowledge and experience to tell the good from the bad.




Just a notice
Posted by: Three-eyed Fish on March 25, 2007 04:23 AM#