Aikau Framework

cancel
Showing results for 
Search instead for 
Did you mean: 

Aikau Framework

Intermediate II
3 19 9,342

Aikau is available on GitHub at: https://github.com/Alfresco/Aikau

The official documentation is at: http://docs.alfresco.com'

Aikau Framework

Aikau is a UI framework that was developed by Alfresco and included in the Alfresco 4.2 release. It was expanded and developed further Alfresco One 5.0. Unlike the majority of Alfresco source code it can be found in its own GitHub repository (https://github.com/Alfresco/Aikau). The project is managed on its own JIRA board (https://issues.alfresco.com/jira/secure/RapidBoard.jspa?rapidView=322&view=planning). There are weekly backwards compatible releases.

The framework consists of a method of loading and defining UI widgets and also includes the widgets that have been built using it.

Usage

4.2

  • Header

5.0

4.2 areas, plus:

  • Live Search
  • Filtered Search Page
  • Search Management Page
  • Site Management Page
  • Analytics and Reporting Widgets
  • Page Creator
  • Document List prototype

Aikau Documentation

There are lots of resources to help developers with the Aikau framework, however these resources are spread out over various different sites. This page serves to collate the resources and act as a single point of reference.

Alfresco's Official Documentation

Tutorials (currently Alpha):

Introduction

Introducing Aikau: http://blogs.alfresco.com/wp/developer/2014/02/26/introducing-aikau/ (Dave Draper)

Community Tutorial

Working with the new Aikau framework in Alfresco Share 4.2 http://ohej.github.io/alfresco-tutorials/tutorial/aikau/tutorial.html and the blog post that accompanied it: http://ohej.dk/2014/07/tutorial-about-the-aikau-framework-in-alfresco-share/ (Ole Hejlskov)

Summit 2013 Videos

Summit 2014 Sessions

Slides and demo videos:

Tech Talk Lives

Mini Examples

Using Aikau With Other UI Frameworks

Share Extension modules

Aikau extensions are done via the extension module approach that was introduced in Alfresco 4.0:

with Aikau specific examples:

Third Party Aikau Extensions

Aikau Widget Documentation

Why did we choose the name Aikau?

The Aikau framework is named after the legendary Hawaiian Surfer Eddie Aikau, named because the framework sits atop Surf.

19 Comments
Established Member II

Great work Dave. In putting all these links at central location. It is always a challenge to find out good and reliable documentations & learning material for aiku. This is going to be very helpful to all developer who wants learn aiku.

Intermediate II

Thanks mittal Patoliya​, very nice of you to say!

Partner

Dave, how about doing the same for Surf?

Intermediate II

The honest answer Bindu is that I'm not sure when I'd find the time to do that... my priority is with Aikau on top of the Share related work that I'm doing as well and I have very little time to pull the resources together, this is also something that anyone in the community could do - I'm certainly not sitting on a wealth of unpublished Surf information. I'm also not convinced there is a huge demand for this information (although I'm happy to be proved wrong by responders to this this thread or a poll) although I know that it is something that you are interested in. Sadly, I think that there needs to be a strong show of support and interest in both Aikau and Surf for the Alfresco PM team to assign resource to this sort of activity.

Partner

Anyone doing serious Share customization needs this info. Currently it requires a lot of research and reverse-engineering. As such the cost of such development is very high and the maintainability is very low.


On the plus side, I suspect folks will be flocking to ADF in the next year or so, given the current state of affairs with Share, so maybe a short-term/legacy problem.


I'm so thrilled that the 5.2 release has seen so much work towards the vision of Alfresco as a platform again, I sure wish Share was also seen as a UI platform in the same way. I guess I'm preaching to the choir though Smiley Happy 

Intermediate II

Bindu Wavell I'd really like to understand what you mean by "given the current state of affairs with Share"? 

What do you consider the current state of affairs with Share to be and where have you derived this information from? I'm really concerned about seeing these types of statements going around the Community and I'd like to be able to do something to address them.

Partner

Dave,

I'm referring to things we have been "discussing" for a few years. My suggestion about improving the documentation for the older parts of Share was my suggestion on how you could "do something to address them." Of course there are likely other options, so I'll try to outline some of the issues we've had over the years.

A key point I should make right up-front is that I'm very much focused on customization and extension with what I'm saying. I'm not talking about net new development efforts except for when we have to create new stuff that works inside of old stuff. And I'm not talking about what you-all do internally in engineering.

While Share is based on SURF there are several different approaches to creating components/widgets that have evolved within the product organization over the years. The most recent approach you-all are preferring is Aikau but there are at least 2 or 3 older approaches that still exist in much larger volume than the Aikau components that are exposed. Similarly there are different configuration and extension approaches that have been documented over the years. I'm not even sure how to categorize this stuff, maybe: Core SURF, SURF components, sub-components, extension modules, a couple different approaches to creating widgets before Aikau, etc. If anyone knows what I mean, could you categorize these with names we could use to make sure we're talking about the same things? Could someone summarize how they are used in Share, how they should be used going forward, how they should be configured, customized and extended?

In my opinion, Share has to balance 1) trying to support folks who have extended older components 2) trying to upgrade older stuff to use newer techniques 3) add enhancements and new features. This is obviously a common dilemma for products especially when they are designed to be extended. Because of these competing goals and I'm sure many others, we've ended up with somewhat of a variety of implementation techniques that require a similar variety of configuration, customization and extension techniques (some examples are: updating the toolbar (all parts of it), updating the footer (consistently for all pages), updating user profile, updating the details screens/components, updating upload components, updating pickers, updating search.)

While Aikau is quite well documented, there are lots of great examples outside of Share, a few great examples in Share and the Aikau team has been very responsive to feedback/bugs, the older techniques are not properly documented or supported (in my opinion.) Mostly the older stuff is "documented" through a series of blog posts (many of which you wrote) and some really old wiki articles. Much of the official documentation has been cut and pasted from old blog posts from you or from older wiki pages. While this information was awesome for folks who needed to understand updates as they were being released; as documentation they don't present a comprehensive clear picture of how Surf works, the ways it has been used by engineering and the ways it can be customized/extended. In my opinion, even the awesome updated docs Martin has been releasing over the last year+ don't do much to improve this situation related to older Share stuff.

So if implementors or Alfresco customers need to hire people to configure, customize and extend Share, they have to hire folks that are very smart/experienced/expensive. These folks often spend a lot of time trying to reverse engineer stuff. This approach to development can often result in sub-optimal implementations that require a lot from support, are brittle to maintain through upgrades.

I am really concerned about this state of affairs as you know well, I've been talking about this stuff for a few years with folks from multiple organizations at Alfresco and advocating different approaches that might help to remediate some of this. On the other hand, I'm excited that Share is now on a different release cycle than the repo as I hope this will mean that folks can take repo upgrades without necessarily upgrading their Share. Since this was only done for new implementations and with the documentation efforts around defining "supported extension points" for Share. This may be less important than I had originally thought. Hopefully folks can focus on the supported extension points and techniques and this will make customizations less brittle and easier to both support and upgrade going forward. For existing customers that are using older versions of Share and the repo the supported extension points can be helpful if they are doing net new development or if they have cycles to refactor their older stuff.

I could probably say more, but this has turned into a rather long write up. I would be very interested to know if other folks in the wider community share my concerns or if I'm out here being neurotic about this stuff all on my lonesome .

Thanks as always for taking the time to engage in these discussions Dave!

-- Bindu

Master

You obviously had to get it off of your chest . I think I share your concerns about "the state of Share" in most regards. It has become a hodgepodge of different approaches and company management / development strategy does not give any indication of rectifying this. For me groupings are more like "legacy YUI component", "unextendable/uncustomizable, legacy 'other' UI component" (i.e. jQuery based calendar), "legacy YUI component with at least some configurability or extension registration built-in" (aka document library / workflows) and "Aikau-based pages which don't re-use existing configureable customizations" (new Aikau support for forms runtime is an exception but as-of-yet not part of the product). Everything is based in Surf and that framework has not changed at its core - advanced components / extension modules are just enhancements to make it a bit more dynamic.
If I had to give these names I'd choose "AnyYUI", "FrankensteinUI", "ConfigurableYUI" and "AikauUI".

"The state of Share" currently is such that any developer needs to be familiar with at least the 2 YUI and single Aikau categories to implement any non-trivial customization of Alfresco Share. And it doesn't help that quite a lot of components in the "AnyYUI" are not easily extendable / customizable (for various reasons that could set me off on a tangent). Unfortunately since developers nowadays are either being pampered, overwhelmed or dumbed-down by fancy-pants UI frameworks (depending on your personal point of view on the state of web development), they are increasingly uncapable / unwilling to work with the older warts. I mean, I feel that unwillingness (or in my case frustration) too, when I have to go do something in YUI again because one of the actually integral bits of the product has not yet been converted to being Aikau-based.

All of this is not a discussion to be had with Dave, but with management of the company to somehow come to "see the light". ADF will not be "the one true future" for Alfresco customer use cases. Significant numbers of customers will continue to need a standardized DMS / collaboration platform that can be customized / tailored to their specific needs via straight-forward configuration and small script hooks, instead of requiring someone to setup a ng2 project. The official party line is that "Share is not going anywhere", but by not having any (publicly recognisable) drive for consolidation / rejuvenation it is effectively being killed slowly as customers loose faith in it or simply cannot adopt / continue to use it for lack of skill / budget needed for dealing with a heterogenous, stagnant system like this.

Unfortunately I don't know what it takes to get the message across. There sure wasn't a lack of nagging on my side last BeeCon, and open skepticism about relevance of ADF this whole year. As a single person - and without any form of community consultation on anything other than technical details / previews when it's often too late - that's about as much as I can do. I don't have the reach or the acumen to come up with a well founded business brief using concrete numbers to show how remedying this "state of Share" should be of vital interest to the company...

Active Member II

I hate to say it but I guess the discussion complaining is over and Alfresco just wants things where they are now. At the end of the day, people will (most likely are already) moving away from Share. Nothing wrong with that, they are free to do whatever they want with it. However, would be fair to make this really clear so people with investments know where they are and what to expect. This all seems fairly strange in current Activiti context and the new aim to go "even more open".

Dave is doing a great job within Aikau scope but that's just not enough to keep things healthy. In fact I don't understand how the completely separated development of Aikau and Surf makes sense at all. Yes, the repo uses plain webscripts as well, but is that a big deal? (Ironically, seems this has just bitten me SHA-1931.)

 

Looking at Alfresco UI history, I wonder how people feel recommending to go with the ADF.

Intermediate II

Bindu Wavell‌ Thanks for taking the time to write up such a comprehensive answer. I completely agree with you on pretty much everything you say. I would very much like to see more documentation for Surf and for Share customization but the question will always be around what the value of it is. I don't actually know what the future for Share will be and I'm no longer in a position to have much influence on it. I also don't set my own agenda for work and what free time I can carve out to work on other things needs to be spent wisely. If I were to spend this time writing up documentation on some of the older concepts around Share/Surf customization then I wouldn't have the time to move Aikau forwards (on things like the recent performance improvements and the forms runtime integration). 

The honest truth is that I don't know how valuable additional Surf documentation would be. I deal directly with very few customers (and in fact almost all of those dealings are done through the proxy of an Alfresco Solutions Engineer) so I don't actually know what paying customers want. In terms of my interaction with the Community I'm usually only dealing with the same dozen or so people on a regular basis - most of whom (like yourself) already have a deep knowledge of Alfresco.  You probably have a much better idea of how important these types of customization are. Alfresco is starting to do more research into what our customers do with Share but I haven't really seen any meaningful output to this yet. It would be really good to be able to put a tangible value on what Share customization is worth to Alfresco (the company) so that the people who make the decisions can say "Yes, this is something we need to invest in because it is driving sales". 

I personally think that Share has tremendous value but I have no data to support that. I also believe that the ability to customize Share is a key differentiator from our competitors, but I also have no data to support that either. Finally I believe that if we converted more of Share to use Aikau then that would make it easier to not only customize but to support those customizations between upgrades (again no data to support this).

It's this last issue that interests me. The original separation of the Repository and Share as I understand it was to allow Share to be released more frequently. In actual fact from your point of view you want the opposite - to take advantage of Repository updates without upgrading Share. My assumption is that this is because you have concerns that upgrading Share will break customizations (a concern that I completely understand)... however, if this is the case then it feels like the wrong solution to the problem because it means that you can't take advantage of the fixes improvements that are made to Share.

This is probably the driving argument for people having their own standalone clients that simply work off REST APIs from the Alfresco platform. However, the issue then becomes about what features and capabilities are required that are different from out-of-the-box Share. This means that people could need to develop and support a huge amount of their own code to recreate many of the features that are readily available and supported in Share. However, if this is what people are going to do then they won't need more Share customization documentation. The point is that I really don't know, maybe it is just a handful of people that want this stuff... if I knew that the demand was there then maybe I'd know if it was worth writing more documentation up on Surf.

Intermediate II

Andreas Steffan‌ It's statements like:

At the end of the day, people will (most likely are already) moving away from Share

...that worry me, simply because I have no idea whether or not it is true.

If people are moving away from Share then as you say that's completely up to them. However does anyone actually know if this is the case? There certainly seems to be no shortage of questions about Share customization being raised in this the Community forums each week so there do seem to be lots of people still using it. 

Intermediate II

I agree that Share is currently hodgepodge of different approaches and I'd personally like to see us invest in weeding out a lot of that old code and either replacing it or just getting rid of it completely. It would be really good if we could have a single application that was both a good out-of-the-box application for show casing new capabilities on the Alfresco repository (as we're doing with things like search term highlighting in 5.2) as well as providing a stable platform with a single consistent approach to customization. 

It really boils down to the issue that I've discussed in a couple of the other responses which is what is the demand for it (predominantly by paying customers since that is what will fund the development effort) and what is the value of it be to Alfresco in the future (i.e. will there be a significant return on that investment)?

The one main problem with replacing/removing existing capabilities is what impact it will have. Let's say we replace the YUI2 Document Library with the Aikau version... this is almost guaranteed to break many customizations (including one of our own in Records Management). So we need to ensure that it's easy to port those customizations, or support fallback to the original Document Library and provide enough enhancements in the Aikau version that makes people want to to move to it.

Active Member II

Let me put it this way: Things don't change overnight and people with serious investments in Share are stuck for a while.

But given current state of affairs, who on earth would recommend investing in Share?

Intermediate II

Me? :-)

Active Member II

I fully agree with regards to Share being a key differentiator. Nuxeo does not have and extensible collaboration app (but it does have its own flavor of an ADF and yeoman gens amongst other things).

In fact, I think the Share situation is even harmful. For newbies, it is most likely the first UI they get to see. A fair bunch of them gets disappointed for various reasons. Some of them draw conclusions way beyond Share - believe me.

Alfresco Employee

Doing a similar effort for Surf and Share is a great idea, ‌. I will take an action item to start fleshing this out when I get back from the holidays. Expect some updates early next year, stay tuned.

Partner

Is this still on your list Ole?

Alfresco Employee

Yes. I have been out on vacation for the last two weeks, and just got back. It's still on my list!

Partner

Awesome, thank you!