topic Re: Developing alfresco-backed web application in Alfresco Archive

Developing alfresco-backed web application

wciesiel — Mon, 29 Oct 2007 11:00:33 GMT

Hi all,Can you suggest (or point me to some article/wiki/forum already describing this topic) proper way to start developing web-application backed by Alfresco WCM? How to update application code-base while developing it in a way easy enough to do it several times a day during development works? Upd

Re: Developing alfresco-backed web application

freedev — Mon, 29 Oct 2007 11:46:49 GMT

Hi,

I think the best document to begin to understand how the things works in alfresco is
2.1 Product Evaluation Guide, but I suggest you to look also at eyestreet sample and the web site framework.

Bye,
Vincenzo

Re: Developing alfresco-backed web application

wciesiel — Sun, 04 Nov 2007 01:41:17 GMT

Hi,

I think the best document to begin to understand how the things works in alfresco is
2.1 Product Evaluation Guide, but I suggest you to look also at eyestreet sample and the web site framework.

Bye,
Vincenzo

You did not understand me. I was asking - what kind of process should I employ to develop SUCH applicationa like that simple web-app used in evaluation guide (the one used in bulk upload). Evaluation guide shows how to set up alfresco managed site with ALREADY IMPLEMENTED site component (that .war). I am asking HOW it should be implemented… For example - how can I update version within alfresco with new source code? It'd be ridiculous to do it on file-by-file basis…

Re: Developing alfresco-backed web application

jenglert — Mon, 05 Nov 2007 14:12:03 GMT

It seems like the CIFS interface might be helpful in this scenario. You can access files inside your webproject via CIFS. Be sure to select the correct AVMStore though, it can be a little tricky.

Re: Developing alfresco-backed web application

kvc — Fri, 23 Nov 2007 01:09:39 GMT

Guys:

A super nice way of doing this is to leverage more of the underlying power of the web content store (the AVM).

Remember, each sandbox is actually its own Subversion-style repo. That means in each repo you have file and directory versioning, file and directory branching, and store-level versioning and branching. A web project is really just an arbitrary association of repos, with one call Staging, others named after their user-owners, and another - usually on one or more remote servers - called live. Repos of course sync via AVMSyncService, whether on the same server (done as an action in our default workflow) or separate servers (done via our deployment service).

Each repo also supports layered files and layered directories. By default, user repos (or sandboxes), have a layered directory that points to their local Staging repo (or sandbox). That way, any content committed to Staging is auto-reflected in all other sandboxes.

Why highlight this?

You can create one web project for your common app code. You can do all your dev in a sandbox via CIFS. When happy, you can check in to your local Staging. Before checking into Staging, you can do local snapshot (via our API) against your sandbox for local versioning. We'll make that easier in a few months with a set of command-line tools.

Now, in all your other web projects, what you'll need to do is create a layered directory using our API that points to your dev Staging repo. This means that automatically, all Staging repos in all web projects will instantly be updated with your new code - and, correspondingly, all user sandboxes as well.

In 2.2 Enterprise, we add support for saving a web project as a template, and allow you to quickly create new web projects from a template. What this feature does is create your new web project's Staging repo by BRANCHING the Staging repo of its parent template. Thus, it starts out with a body of content. You can sync as you wish to stay current with updates. A sneak preview of this can be found on our wiki.

This feature can be used in conjunction with layered directories. Create your web project for your code, create a default web project that has a layered directory pointing to the layered code, and then create all your web projects by branching from that template. Viola! You only need to create the layered directory once. Everyone automatically gets its - and all code updates.

This is the same thing we recommend for corporate brand assets and common content libraries as well. Create them in their own separate web projects - they don't actually have to be complete websites themselves. They are just shared resources. Resources we make very, very easy to share via layers.

Take a look under the covers at what really possible at the API layer. It's really, really powerful. We look to expose more of its capabilities in the web client over time in future releases.

Cheers! Have fun discovering … the repo is a powerful thing.

Kevin