Customising the Alfresco Webclient: Best Practice

[lnagra]

This questions concerns codebase structure and best practice for developing applications using the Alfresco web client.

As Alfresco is an open source project that enjoys a rapid release cycle, I am keen to ensure that my work stays seperate so that I'm able to take advantage of new functionality without breaking my application.

What is the accepted practice for customising and building on top of the web client. Of course, I could simply edit the source and use the existing structure used by the web client, but I would then lose my changes on every version upgrade of Alfresco.

Specifically, I would look to:

1. Alter the GUI presented by the Alfresco web client to simplify it for our neeeds
2. Create my own wizards
3. Create my own workflows

Any guidance from the community and Gavin or Kevin is appreciated.

Thanks,

[turgayz]

Hi,
I tried to implement "task lists" for Alfresco, you can find the discussion in the "Developers-Web Client Development" forum. And I am facing the problem you have, keeping my work seperate, and ensuring that I am in synch with official Alfresco sources.

If you *add* files, then that won't be a big problem. But if you need to *change* original Alfresco files, then you need to watch for changes done by the Alfresco team, and keep in synch. And I bet that you will need to change some files, at least browse.jsp.

I can suggest to work on the latest sources all the time, synchonizing with the Alfresco subversion sources. Then, if any file you have changed is changed by the Alfresco developers, you can merge the differences. Then your changes can be valid as for the latest Alfresco code.

If there is a better practice, I would also like to learn it.

[paulhh]

Hi

As well as looking at UI redesign, we're also trying to make it more extensible (in the short term, just making faces-config overridable would help).  Once we get to thinking about the design, we'll start discussing it in the forums for feedback.

Cheers
Paul.

[lgr]

Hi,
I tried to implement "task lists" for Alfresco, you can find the discussion in the "Developers-Web Client Development" forum. And I am facing the problem you have, keeping my work seperate, and ensuring that I am in synch with official Alfresco sources.

Hi,

You have the beginning of an answer in the two following posts :
http://www.alfresco.org/forums/viewtopic.php?t=696
http://www.alfresco.org/forums/viewtopic.php?t=712

There will be in the future a process so that Alfresco team centralizes modifications done by community users. But of course, every community developper will have to support its own developpement, Alfresco Team will not maintain it.

Developping and sharing new wizards or workflows should be great, and could be done through this process.

Anyway, afaik, nothing about a web interface customization service implemented in Alfresco.

Laurent.

[turgayz]

Hi Laurent,
I think the discussion here is not about licensing or legal issues. Of course that is an important topic on itself.

Problem here is, how to keep in synch with the Alfresco sources, that is, the code produced by official Alfresco developers. If everything could be an *extension*, then there would be not much problem, you could easily track the changes *you* have made on the sources. Of course there are some areas where this may be improved, but I don't think it is possible to make every change as an extension.

For example, you can put your own definitions of new types and Spring additions also, in the file alfresco/extension/extension-context.xml. But, you will also need to change some original files to put in new functionality, like showing a new context menu item for spaces. I had to change browse.jsp, document-details.jsp, space-details.jsp to have this addition. There you have the problem of ensuring that your changes stay current with every version change from the Alfresco developers in the future.

As I said, of course the licensing topic is also very important, I have read the topics you mentioned.

[lnagra]

@ turgayz

I can suggest to work on the latest sources all the time, synchonizing with the Alfresco subversion sources. Then, if any file you have changed is changed by the Alfresco developers, you can merge the differences. Then your changes can be valid as for the latest Alfresco code.

This is a good idea and could work quite well for our initial development. Such a system forces you to continually accept the latest Alfresco code changes. As Alfresco is still in 1.x, I guess it's not a bad idea to keep on top of the changes so you don't fall behind.

However, I'm not sure if it would be a sustainable method of development. Particularly when the time arrives to deploy and put into production your Alfresco-based app.

@ Laurent
Thanks for the pointers on the licensing issues. It would be interesting to hear how the Alfresco team would potentially manage a situation whereby functionality available in the enterprise edition is duplicated and released by the community. But I'd imagine that's a topic for the Licensing forum.

@ Paul
What's the anticipated time frame for these changes. Are there any live implementations of Alfresco that have come across or dealt with this problem or is the method advocated by turgayz the currently accepted solution?

Thanks,

[lgr]

Hi All,

You're right, my post was not very clear. The information i wanted to point out is that the Alfresco want and will organize itself for being able to accept modifications from the community developpers.

I think the product and the organisation is not ready yet for providing software interfaces, internal customization and graphical change processes, for the community. But these posts in the licencing forum make me think that Alfresco will be able to do so in the future.

Anyway, i've got no information about these change timeframe or roadmap priority (except in the wiki,  Release Quarter 2006 1 and 2 : Personalization and Extended Workflow Capabilities (http://www.alfresco.org/mediawiki/index.php/Roadmap)).

Hope this helps

Laurent.

[gavinc]

Hi,

Yes, unfortunately at the moment as far as the client is concerned you will need to change some of our files until we have the extension hooks Paul mentioned in place.

By the time the final 1.2 release goes out the configuration in the client WILL be more extensible, basically, you can override anything in a separate file and you won't need to change ours. Hopefully this will also be the case for the JSF config files.

There should also be some documentation on the wiki soon regarding client configuration, this may well also cover some simple customisation examples.

[kevinr]

Many of the extension hooks are now in place for the 1.2 final release:
http://www.alfresco.org/mediawiki/index.php/Web_Client_Configuration_Guide

Thanks,

Kevin

[rdanner]

Anywhere configuration can be used to direct, if not declare behavior, is ideal. One of the places in alfresco I have found to be the most difficult to extend are the places which have a lot of case logic around assumptions IE choosing what editor to display (assumes that the differentiation is mime type) or wizards etc.

One thing I would look for is to bring IOC to the method level. Break the methods up in to small atomic operations that can be wired together through configuration. If the configuration is override-able (merge-able is better, but more difficult), then you can really kick the case logic issue in the rear. It becomes a non-issue.

The other place is panels in the JSP. One think I would look for is the use of tiles in JSP and a declarative way to say bring in this tile at this time in this location.

The other place that is interesting in terms of overriding behavior is environment. Sometimes I want my dev environment to act different then my production environment (IE… send the emails to a different account or for instance use a different database etc). Spring provides for this to some extent.

You have properties files…. eh
and you can override beans by adding wild cards to the names of the context-xmls in you web-inf.

ie

   <context-param> 
     <param-name>contextConfigLocation</param-name> 
     <param-value> 
        classpath:app/contentRepositoryBrowser/application-context.xml, 
        classpath*:app/contentRepositoryBrowser/*/*-context-server.xml 
     </param-value> 
     <description>Spring config file locations</description> 
   </context-param> 
‍‍‍‍‍‍‍‍‍‍

This is ok…. I am not stoked that configuration relies on class path as it gets in the way of some of the things I want to do (in terms of granularity).

Class path works great for web apps in the traditional sense but not in terms of portlets where you can instantiate more then one of the same type and you want them to be the same app configured a new and interesting way. In this case you need to rely on two configuration stores. Spring as a default and the portal engine as the instance.

Anyway it gets the job done.

The more stuff we can drive in to configuration and in to the inversion of control concept… the better.