Interview – John Cox of Xaraya
Published (updated: ) in Uncategorized.
Originally published on SitePoint.
John Cox is a member of the Project Management Committee for Xaraya, an advanced content management system currently being developed from members of the old PostNuke team. Recently, I asked him a number of questions about his role, and the Xaraya system.
Firstly, John, can you tell us a little about yourself, and your involvement with the Xaraya development team?
The Xaraya organization is based on the Apache model for open source development. I am one of the four on the Xaraya Project Management Committee. I mainly oversee the release timelines, and do my best to communicate the project’s objectives within the development team, and the community at large.
Marcel van der Boom and Paul Rosania are another part of Xaraya’s PMC. They look at the design and underlying architecture issues of the project. Gregor Rothfuss rounds out the PMC team by overseeing the administration areas, and general research and development.
The PMC is a very small part of what makes us go, though. The team work and camaraderie is the strength of our development, as each one of us chips in with the glamour projects as well as the mundane tasks. We each play a part in the project with support, communication, marketing, design, development, steering, and documentation.
In PostNuke, we played around with role based management and development, but learned that it just created new layers of complexity which gained us very little in the grand scheme of things.
Xaraya is an advanced site management system much like the PostNuke system. What advantages and features does it have over the other systems currently available?
While the comparisons are inevitable, I believe that there are more contrasts that can be made from Nuke-style portal systems to Xaraya.
*Nukes (and there are too many to list, to be honest), gain their popularity from a somewhat simple design which allows the community to plug in to the module system and add to the functionality.
There is a fundamental flaw with the current systems, however, in that in order to extend the functionality, you have to have some knowledge of PHP. The more extensible you want to get, the more grief that you cause yourself at the time of upgrades in that you’ve probably created a rough dependency, or — worse yet — changed a core file that will be overwritten. The results of this could be anything from causing quite a bit of frustration, to inflicting downright agony.
Xaraya is different in this respect.
We wanted to make the system more extensible for the average user, and give more power to the module and theme developers out there. We’ve done this in many ways.
Primarily, for the Webmaster, we have built a system that allows you to create new publication types in a matter of minutes. This alleviates the need to wait for the whims of someone with similar needs if you have no PHP knowledge.
For the developer, we have created a very easy to use API, which after a little study makes the development of modules extremely easy and extremely fast. In addition, Frank Besler and Marco have created the events system, which allows the module developer to plug directly into core events so there is no need to change files which will be overwritten on an upgrade.
Finally, we’ve given designers the power they need to create a look and feel that’s not dependant on hard coded design techniques from within the modules, as all output is a template, and can be overridden from theme to theme.
Another advantage over the *Nukes is our privilege and role based system designed by Marc Lutolf. It is easy to use, and also very flexible, which gives us quite a bit of an edge over the *Nuke systems at this point. Marc redesigned the group/user system from the ground up with an approach that kept the flexibility from our PostNuke days, but entails a much easier approach and is much less intimidating for the novice user.
What aims did you have for the project when you first set out? What made you decide to start developing this new system?
It all started as a desire to finish our “better mousetrap.”
Xaraya itself started because of fundamental disagreements in what the mousetrap should look like when it was finished during our time at PostNuke. When you put passionate people together long enough, good and bad things can and will happen. This was the case last year with PostNuke development. The folks that stayed working with PostNuke are all very competent professionals; however, change was needed in order for our original vision to be realized.
The reasons for the development remain the same today as they were nearly two years ago when Greg Allan, Sean Finkle, Harry Zink, and I began PostNuke. We wanted an extensible content management system to perform a variety of different functions on Internet and intranet applications. We wanted something that provided just the bare necessities and allowed plug-ins to do the work of the functionality. Xaraya 1.0.0 is the completion of that vision.
Why have you decided to separate the 4 elements form, function, content, and design? What advantages does this pose?
Separating the processing from the presentation allows quite a bit of flexibility not just on the output side, but on the processing side as well. We aren’t tied to displaying the strict output of a query or a function, and enjoy greater flexibility to manipulate and massage the processing to several desired effects.
The original system was designed by Jim McDonald during our time at PostNuke, but has since been extended to a new level by multiple sources within Xaraya (Paul, Marco Canini, Flavio Botelho, Michel Dalle to name a very few).
It is much easier to re-use queries from multiple input sources, rather than using inline sources to do the same job. For instance, here’s an example of a work flow for non-separated output:
The user enters information into a form. That information is sent to a function which first does checks and cleans the input, (hopefully) looks up the desired information, and then displays the result. For each other form or action, repeat this process. It’s very difficult to separate out this output and process it in multiple fashions, and it is also difficult to reuse the query to do a similar action (although not impossible). It’s a linear process which is difficult to extend.
With Xaraya, the work flow differs, as several different processes work together to produce a single, or multiple, desire effects. The form or action is still completed by the end user, and the input is still validated, but from there it can go to multiple parts of the system, in accordance with user preferences.
The queries are performed in a non-linear way, which provides the ability to reuse code, and creates true consistency throughout the Website. One query could be reused by 50 functions. In addition, one module could be called by many others (depending on preferences), allowing much accelerated development.
There is no reason to rewrite a comments system multiple times. Instead you can call the comments to display via a hook, or you can make direct API calls into the comments to gain finer control over the output that the end user sees.
Why would a Webmaster want to use Xaraya on his/her site?
I initially got interested in content management for several reasons. More frequently I needed to dynamically generate items so that I wasn’t stuck creating a static site over and over again. I am lazy, quite frankly, and I want to concentrate on my content and design, rather than constantly have to worry about manually uploading and updating html pages. Xaraya gives the Webmaster the ability to leverage their design and content skills, and no longer worry about the small mundane duties that go into maintaining a Website.
These are very general reasons of using a content management system and have been sold to most Webmasters already. CMSs are a dime a dozen now, so, to stand out from the crowd, paradigm shifts are needed in terms of understanding what actually can be done to make a Webmaster’s job easier.
The articles system, combined with the dynamic data system (both written by Michel), means a Webmaster no longer has to wait for developers to dream up new modules. All the Webmaster has to do is dream up what they want to display, and from there it’s just a matter of adding two templates into the system, and creating a new publication type to gather the data.
Here’s a recent quote from one of the people from our mailing list who has been playing with Xaraya:
“Do you guys/gals have any idea what you’ve achieved here? Silly question, I know. You have given me a CMS that is capable of showing almost anything in any way that I desire. This has always been the dream of other CMSs. No longer must we wait while someone modifies the guest book, No more waiting for someone to develop a recipes module. No longer waiting for someone to add categories to the reviews module and on and on…
You have given the common user the POWER to be a self sufficient Webmaster…” – Craig Hamlin 5/28/03
Xaraya is still in development. How far along the line is it? Do you have an estimated 1.0.0 release date?
Unfortunately, I can’t estimate the final stable release. I can say that I expected to find fundamental flaws with the design during the Beta process, and I am happy to say that none have been reported as yet. So, the design is for the most part, stable, but the “attention to detail” items remain. Small changes and fixes take a good deal of time to get exactly right. In addition, we have code consistency to think about on both the display and code sides, in order to give a polished feel that everyone desires.
That said, even in development process, we take time and effort to ensure we make quality changes. A good deal of work has been diverted to complete unit testing on the code base. This has been fully developed with our XML parsing routines and has the desired effect of producing higher quality code than that sometimes found in open source CMS systems. That is not a slight on anyone who spends their free time developing a tool for others to use, it’s more an indication that we’re dedicated to doing the project right.
The most popular systems, PostNuke and phpNuke, provide extensive support for customised styles. Xaraya also has this support, but what makes it worth using? How customisable is the styling system?
Every output that Xaraya shows is from a template. The *Nuke style systems allow a custom theme (there are some advanced versions for both PHP-Nuke and PostNuke) which provides the user some control over the output. Both those systems also have some style sheet control over the output, but in many cases it’s inconsistent within the modules (or even the themes themselves). All of this is moot with Xaraya.
We’ve introduced a template system that allows a designer complete control over the entire output if they want it. Each output template can be overridden within a theme so that each theme can produce a completely different style of site. Going even further, there are various other override controls within the template system that allow a designer to create a consistent UI to administer the site, while presenting a completely cutting edge design to visitors.
In addition, what’s really valuable is breaking out the output so that it can be displayed in various formats (limited only by your imagination). Need to print something, but don’t want to load extra CSS on a page view? You can do that with a theme. Want to display something in RSS format? That can be done as a theme as well. Do you want to have your Website only generate PDF documents? That can be built into a theme. Want to be really cool and amaze your friends with your XUL knowledge? Guess what? That’s as easy as building an XUL theme (which we already have a proof of concept design somewhat working).
In addition, Marty Vance (among many others) has spent a great deal of time on the CSS standards for Xaraya. His work provides even greater control, allowing the non-designer to change quickly the formats of their themes without undertaking considerable work on the presentation layer of Xaraya. We haven’t spent much time working on showcase themes to exhibit the functionality, but as we wind down development and have the time, we will be showcasing the functionality. In the meantime, we’re answering questions and hoping some of the early adopters of the technology manage to wow us first.
What can you tell us about the module/block system?
The module/block system is where the functionality of Xaraya is plugged in. By itself, Xaraya doesn’t do a whole lot. It manages users, and provides the backend so that the functionality can be tailored from site to site. The modules provide the functionality that you see when you visit any site built with Xaraya. They process information, then send it back to the screen to be displayed.
The blocks are very similar, except I look at them as “helpers”. At this time we can process on module instance (plans are in place to move to a more page-type display), but you can introduce blocks to help the functionality along. Blocks get their name from the *Nukes, but despite their name, they have nothing to do with the display feel they need to take.
For instance, we use the blocks to process Meta information. By doing this we created a header block that’s displayed in the
</head> portion of a page, and adds to the dynamic processing of that page. Any module can send its content to the Meta block, and the Meta block can generate dynamic Meta keywords.
Usually, there are similar design elements to any Web page. You have some sort of navigation, maybe an advertisement, possibly a small reminder or teaser note, and finally you have the content. Xaraya makes it possible to dynamically generate these individual design elements. If we take the example above, the module would process the content while the blocks handle the rest.
What are your plans for the future in regards to this site management tool? And how will it develop after the initial release?
Marcel and Paul have been working on the vision document for the 2.0.0 release cycle. We will have another election for the PMC around the 1.0.0 release, and we’ll go from there. We’ll make the 1.0.0 release the benchmark by which others are measured (and that’s tough, considering the market, but everyone needs goals!), all the while tearing down our “better mousetrap” and creating an even better one.
As to how that will look when it’s finished, I can’t say. My plans are to step back from the PMC, spend more time on the code after 1.0.0, and let someone else have the fun of guiding us.
We will, more than likely, follow the same path we did when we started, except now we will have a stable release to support. Incremental releases and benchmarks are fun, but they tend to slow development, as we have needs for feature freezes and support issues directly following a release. Hopefully, we’ll have a stable tree, while parallel development occurs with the development tree. It alleviates the boredom of staring at the same code every day.
You’ve spent endless hours coding and supporting customers for free. What’s your motivation for doing this? Do you plan to ever make money out of this project?
I enjoy having a hobby. If I wasn’t doing a CMS, I’d be collecting stamps, building model airplanes, or one of the myriad of hobbies that others have. For me, this is just fun. At times it can be tedious dealing with the occasional troll, but on the whole I wouldn’t trade the experience for anything.
As for money, I’m like anyone else, and would love to spend all my time doing what I find most enjoyable. I may attempt to consult, or find some other opportunity after someone else is running the show, but for now I’m pretty content and look at the time I’ve spent as a learning experience. I’ve made many new friends, and money just can’t buy that.
The Xaraya project is currently at version 0.9.0.4 and is therefore almost complete.