Accolades and questions

[ftoth]

First let me say that I'm thrilled to have discovered Alfresco recently. Everything about the architecture feels right. We have used hibernate, lucene, spring, jbpm, freemarker, etc., in past projects and it's fantastic that Alfresco is built on such a string foundation. The more I read, the more I discover new nuggets of functionality that I can use!

I'm looking forward to the WCM preview, and I'm sure that will help answer some of my questions.

The area I'm most interested in at the moment was referenced in a previous post as "decoupling content management from delivery". This is an area that's dear to us. One thing that's discouraged us from using other CMSs is that they often impose themselves as the actual delivery engine. That won't fly for us. We might be enticed to use drupal, for example, for a CMS, but we will seldom be willing to deploy a PHP site.

So how does this work in Alfresco? Say for the sake of argument that we are deploying a ruby-on-rails site. We'd still like to use Alfresco to manage users, permissions, template editing, content editing, etc. But the end result will run in a rails environment.

The same example could apply to other java environments. Say we have a webwork site with its own set of run-time data models, beans, services, etc. But I want to use Alfresco! We still have users managing content, templates, preview, the list goes on…

From everything I've read, it sounds like you guys have been thinking about this, but it's not clear to me how it would work in practice. How could we have preview capability for a rails site?

Before I read the recent updates to the WCM documentation, I was imagining that I could write my own preview function. Perhaps we run our site in the same JVM as Alfresco, and our preview uses Alfresco APIs to extract the templates and content. Maybe we hack Freemarker so that its "include" function somehow knows to query Alfresco?

But in your new WCM doc, you mention "Alfresco runtime". Again, I can see this as being a very practical solution for some, but not all.

I welcome your comments. And I'm looking forward to more Alfresco.

Thanks,

Fred

[jcox]

First, thanks.  We're trying hard to enable everybody – from the unsophisticated user who just wants to get something basic up & running quickly, to the power-user who wants a highly modular and configurable system. Our ideas for deployment are derived from this dual goal:  we'll have something decent in place by default (eventually), then we'll provide various tools/APIs to let you customize things as you see fit… including having no Alfesco software on the live runtime site at all.

The decision to make the live site totally decoupled  from the CMS, tightly coupled to it,  or somewhere in-between (e.g.: callouts for specific pages) should be one for the content administrators to make; it should not be dictated by the design of the CMS they're using.  An all-or-nothing CMS limits its own growth. 

As for source code management, it's our strong desire to develop Alfresco within Alfresco.  We're very grateful to Collabnet and the Subversion community; however, I think the scope of what we're doing is a bit broader  (e.g.:  CIFS, transparent overlays, the GUI, workflow, and so on).  Therefore, Alfresco will end up doing SCM, WCM, and DCM.   However, we'll continue to provide public SVN-based access to our source code, no matter what.  We want to "eat our own dogfood" as much as possible.

I can't say much about Ruby in particular other than that I like it.  It shares the "oh-get-on-with-it" philosophy of Perl, yet it has a much cleaner syntax.  Cheers!

Right now, in-context preview is in its infancy.  There's a single virtualization domain/port for everything in the entire system, which is used by what is currently a non-configurable URL generator.  This make a little "eyeball" icon near assets pop up a preview window when you click on it.

Ultimately, I want to make that URL generation logic context-sensitive and configurable.   Networked access to the repository will probably be via a few different interfaces (CIFS, JCR, JNDI, possibly native…dunno yet).

We'll be posting details of the default deployment setup over the next few weeks.

  I hope this helps,
  -Jon