Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
Design Discussions
One reason I really appreciate Alfresco is that it has a strong identity with the content repository responsibility. It doesn't look like it is designed to do more or less; it's a repository (with some pretty interesting concepts i.e. Aspect Oriented Document management [AODM].) This is evident in the way Alfresco relies on BPEL for complex workflows rather then implementing some sort of home brew internal workflow engine. Alfresco worries about repository issues, BPEL worries about workflow issues. Great!
I don’t want a solution that is my content creation facility, is my repository, is my workflow, is my website, and is my authentication / authorization facility, etc. I'm looking for a solution that can work with other solutions, one that does one thing and one thing well. Object orientation and system integration concepts go hand in hand.
The architectural question is: What is Alfresco's role in the responsibility of web presentation of content?
Obviously there are integration touch points; but is there a real role for Alfresco to play? I see alfresco as a repository containing my document artifacts (copy, layout, metadata, statics, etc). Its responsibilities are things like version control, auditing, some level of rights management, indexing, serving requested artifacts, etc. (I am probably missing a ton here... I really need to start digging in to API(s).) I think it would be troubling if alfresco were doing any rendering, actual delivery of content, workflow, and other concerns.
The movement of documents is the shared responsibility of the workflow engine, and any integration infrastructure (i.e.: ESB.) The workflow might even rely heavily on integration infrastructure.
In short, when it comes to the presentation on a website, I am curious to know what others think is the proper role of alfresco. For my part, I don't see it as doing more then serving the content as an implementation of an enterprise service.
In terms of bringing content to a site I think the issue is something that is a bit complex and it needs to be broken down so the problem can be handled in simple ways.
When you are bringing together a page you have all kinds of components
- statics
- metadata
- renderables (design [XFO, CSS, TEMPLATES, XSL, etc) & copy artifacts, XML)
- functional components (forms)
For the last 8 years we have been trying to look for the best way to bring these things together which gives us the right level of usability while maximizing the reuse.
We tend to pendulum between to worlds... the highly reusable, and the highly user friendly. HTML (heh) is very friendly (when it's tooled) but it is not very reusable. XSL/XML is highly reusable, but it is not very user friendly. To top things off... We need to place functionality in the mix if we are going to have any kind of interesting website(s).
The question here is: how can we bring these things together in a way that is both user friendly and yet maintains a level of SoC, which enables a high level of reuse?
For some time I have had my eye on JSR-168 Portal standard from JCP as a means of tiling a website. When it comes to managing tiles Portal is the place to be. I say that with the reservation, that today most of the JSR-168 portal implementations have a lot to be desired. Let me peruse the though just a bit further.
Am I saying that portal is the full solution? No of course not. However I think portal may serve a number of presentation tier concerns that make it worth added to the mix when it becomes ripe.
- portal offers the basic tiling mechanism / infrastructure.
- portal offers a single sign on platform which becomes more important when we start looking at DRM.
- portal offers a way for me to offer functionality along side content.
If we peruse this line of thinking in the end we end up with portlets that expose functionality and a portlet that renders document artifacts into presentable content.
When it comes to functionality I could not agree more with Alfresco in that, it runs as a portlet but also as a stand alone application. Applications or functionality have an entirely different lifecycle then content and thus it needs to be managed differently. Managing the two the same way is likely to cause cohesion, and in the end limit reusability (at best.) J2EE has taken java web applications a long way with its packaging and deployment model. Prior to J2EE many sites managed JSP artifacts as content rather then application artifacts (Sites built containing both content and functionality), propagating the docroot mentality. If you treat the two the same you have a mixture of concerns, application deployment becomes both a build issue (scm) and a content management issue (csm). It's a bad place to be 
I think we should be mindful of the two different types moving forward, we dont want to mix the same two concerns, but, in just a different way.
for me the questions that remain are
- what components/approach is used to build a rendering application?
- what are the appropriate hooks for caching mechanisms and content retrieval services
- what are the appropriate hooks for caching mechanisms and content retrieval services
- what is the best way to deploy language and skins to prepackaged (skinable) applications?
