Introducing Aikau

by Dave Draper

Introduction

For some time now I’ve been writing blog posts that refer to the “updated UI framework” describing a new approach that we’ve been working on for further developing Alfresco Share. This is a fairly ambiguous (as well as lengthy) term to use to describe what we’ve been up to and we thought it would be sensible to come up with a project name that encapsulates the work that we’ve been doing. The framework is completely reliant on Surf so we wanted it to be somehow Surf related so after throwing a few ideas around settled on the name “Aikau“. This post is going to attempt to describe exactly what Aikau is and why we’ve been working on it.

What is Aikau?

Aikau refers to a method of creating new Surf Pages or Components comprised of small atomic widgets. The widgets are referenced in a JSON model that can either be defined in the JavaScript controller of a WebScript or as a document stored on the Alfresco Repository. Each widget is an AMD module that references it’s own CSS, HTML and i18n resources Surf will ensure that all of those resources are imported into the page loaded by the browser when that widget is referenced in the JSON model that defines that page.

The widgets are intentionally de-coupled over publication/subscription communication and event frameworks so that widgets can be easily added/removed/changed within a JSON model without causing any missing reference errors. Each widget is intentionally designed to implement a single piece of function, but can themselves define JSON models of child widgets so that it is easy to define re-usable composite widgets.

Each widget should be written with customization in mind – methods are kept short and variables abstracted to allow configuration and allow customization through targeted method overrides in extending widgets.

Aikau also provides an Intern.io based unit testing framework and each widget should have it’s own unit test (although we don’t yet have 100% code coverage) to ensure that functionality is not broken during development. We aim to make use of tools such as Grunt and Vagrant to allow continuous testing to run in parallel with development to catch breaking code immediately (although this effort has not yet been completed).

What Are The Goals?

The primary goal of of Aikau are to:

  • maximize code re-use
  • make UI development faster
  • make it incredibly simple to customize pages
  • allow continuous iteration of existing pages.

Aikau leverages the existing Surf extensibility capabilities to allow a default JSON model to be manipulated by 3rd party extensions. This allows pages to be heavily customized without needing to access or work with the source code of the page – it is possible to isolate the customization work to just the specific target areas.

Performance improvements should also be achieved by only loading the minimum amount of JavaScript and CSS data into the browser and by reducing the number of HTTP requests to an absolute minimum.

One of the main benefits of Aikau is that it allows you to quickly prototype pages with existing or simple widgets and then refine them over time. Functional pages can be easily constructed in minutes (and hopefully in the future entirely via a drag-and-drop page creation tool within an application itself).

Surf now supports Theme based LESS CSS pre-processing and widgets are written to be completely theme-able. This allows functional pages to be have their design modified repeatedly over time without needing to throw away existing work and start over from scratch.

How Does it Work?

There have been numerous blogs over the past year that have described the work we’ve been doing – although none of them specifically refer to Aikau by name, the knowledge is already out there!

Essentially Aikau is powered by Surf and uses the Dojo AMD loader and widget templating capabilities to provide a basis for dynamic dependency analysis. Each JSON model is dynamically analysed for AMD modules and those modules themselves are then analysed for their dependent modules (and so on, and so forth) until a complete dependency “layer” has been constructed for that page.

Surf caches module dependency relationships as well as page dependencies to ensure that only the minimum amount of analysis is done to maximise performance.

JavaScript Framework Ambivalence

Although Aikau makes heavy use of Dojo for the AMD loader and widget templating, it is by no means forces the exclusive use of Dojo. it extends the AMD paradigm to allow non-AMD dependencies to be easily referenced by widgets and is completely ambivalent to the JavaScript framework being used.

We have already made use of numerous other JavaScript frameworks and projects within the current suite of Aikau widgets including:

  • “Legacy” Alfresco JavaScript code
  • YUI2
  • JQuery
  • ACE
  • JSON Editor Online

Summary

It’s still early days, but we now have a framework and an initial set of widgets that make page development using Aikau a reality.  It’s unlikely that Aikau will ever completely replace the existing Share implementation but it is intended to work in harmony with it as well as providing the infrastructure to quickly develop alternative Surf based Alfresco clients.

The goal of this post is simply to allow us to talk about Aikau and for you to know what we’re referring to!

 

15 thoughts on “Introducing Aikau

  1. Pingback: Unit Testing Aikau | Alfresco Developer Blog

  2. Dave Draper Post author

    @Jeff – mine is non-existent, but I’m reliably told that phonetically it’s “Eye-Cow” (that’s what we’ve been going with anyway!)

    Reply
  3. Andreas Steffan

    Hallo David,

    first of all I would like to say that I really appreciate your efforts making Share easier to customize. Keeping methods short helps and is generally a good thing.

    Speaking about Alfresco extensibility really strikes a nerve for me. I frequently hit road blocks when I work on extensions – of various type and across all layers of the Alfresco stack. I understand extensibility is a complex topic, but I think there are things which could be changed with little effort and a minimum risk.

    In the Java world for example, private and final modifiers tend to get in my way. Various methods (in Java and Javascript) begging for extensibility are way to long. I personally think it is enough to say “Beware !” instead of “No way !”.

    As things stand today, I often go for the dirty, hacky (and usually much shorter) route to get things done.

    Thanks a lot for making a Share developers life easier
    Andreas

    Reply
  4. Dave Draper Post author

    @Andreas – thanks for your feedback, it’s greatly appreciated. It is definitely a tricky task to retrospectively fit customization to an existing codebase and also to integrate a new framework into an existing application (and it’s especially challenging with JavaScript) but I think we’re getting there!

    I’m hoping that Aikau will allow us to have different “tiers” of customization… from simply applying 3rd party extension modules, to writing extension modules that manipulate a default model, to writing entirely new widgets. Each tier will require a varying level of ability but should hopefully be able to make customizing Share less of a challenge and hopefully avoid people needing to resort to the sort of hacks to which you refer.

    We’re still a long way off achieving that completely – but hopefully we’re on the right path!

    Regards,
    Dave

    Reply
  5. Pingback: Updates to Page Creator Tool | Alfresco Developer Blog

  6. Pingback: New tutorial on Share customization with Alfresco Aikau | ECM Architect

  7. Pingback: Alfresco Community 5.0.a | Kev's blog

  8. Pingback: Alfresco Community lanza su versión 5 | keensoft

  9. Pingback: Alfresco Community has launched version 5 release | keensoft

  10. Peter Horak

    @Dave – thanks for your post arround the new Aikau framework. As far as I understood and explored the new software and concepts are not supported before CE 5.0.a (or 5.0.b-SNPASHOT). Is there any recommended and running setup for a Maven project (both repository and share project) regarding Alfresco version and Maven plugin (alfresco-sdk-parent) version.
    Alfresco 5.0.a (and even 5.0.b-SNAPSHOT) are not working with alfresco-sdk-parent 1.1.1 (and even 2.0.0-SNAPSHOT) right now if you create fresh projects using the Maven alfresco-amp-archetype.

    Regards
    Peter

    Reply
  11. Dave Draper Post author

    @Peter – currently there isn’t a recommended setup. I need to co-ordinate with Gab/Ole on what would be required for the SDK. Now that we’ve moved to Maven we’ve been able to improve things so that you should be able to run the unit tests without much overhead. Hopefully we’ll have something in place by Summit. Once 5.0 is released I should also be able to get more blogs done to help people get up to speed with development.

    Reply
  12. Pingback: Inbox plugin for Alfresco using the Aikau framework • SoftwareLoop

  13. Alen Subat

    Hello there, just messing a little with these new changes and Alfresco 5.0, new Maven, share archetype and whatsoever. I have a small free-time project of mine, which involves porting some (and in the end, hopefully all) share-extras extensions from ant to new maven (using aikau logic). Any suggested approaches? Or it should be just a straight forwarding copy-paste? AFAIK some of the normal extensions/customizations procedure are changed now, right?
    Btw, great work :D

    Reply
  14. Dave Draper Post author

    @Alen – it should mostly just be a copy-paste exercise. However, it would be worth double checking that each Share Extras extension works against 5.0 to save yourself the effort of porting anything that no longer works. The extension/customization procedures haven’t changed though.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>