Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Hyland Connect
- Enterprise Platforms
- Alfresco
- Alfresco Blog
- The Alternate Realities of Share Development
ddraper
World-Class Innovator
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
11-24-2014
05:41 AM
By Dave Draper, Kevin Roast, Erik Winlöf and David Webster
Over the last 4 years (from versions 4.0 through to 5.0) there have been a number of changes in relation to Share development and customization.
From an outside perspective the decisions that have been made might appear confusing or frustrating depending upon your particular use case of Share. If you've written Share extensions or customizations for previous versions then you might have hit breaking changes between major releases and you might be fearful of it happening again.
It might seem that we don't care about these issues. We’re sorry if you have experienced such problems but we can assure you that we try our very best to move Share forwards without breaking what has gone before.
In this post we're going to highlight how things are better than they would have been if different decisions were made.
Back in 2010 we introduced an extensibility model that enabled us to dynamically change a default Share page via an extension module. This was an initially coarse customization approach that enabled Surf Components to be added, removed or replaced as well as our custom FreeMarker directives to be manipulated.
This in turn paved the way for us to refactor the Share WebScripts in 4.2 to remove the WebScript .head.ftl files and push the widget instantiation configuration into the JavaScript controller.
If we hadn't have taken this approach then the method of customization would still be copy and pasting of complete WebScript components to the 'web-extension' path.
This wouldn't have stopped breaking changes between versions (e.g. the REST API changing, the Component calling a different WebScript, different properties or URL arguments being passed, etc) and would have required constant manual maintenance of those WebScripts with code from service pack fixes as necessary.
We know that a few customers still use heavily customised versions of Explorer and the fact that we've finally removed it from 5.0 is going to cause pain to a few.
It has been suggested at various points over the last 4 years that we could create a brand new client to replace Share - even though Share does not yet have complete feature parity with Explorer. We recognise now that we need to invest in Share and improve it over time since creating a new client would ultimately introduce more problems than it solves.
However, when calls were strongest for writing a new client, the recommendation was to move to either GWT or Vaadin. We're fairly sure all those people that lament the fact that this week we're not using Angular would be horrified if they were now stuck with a Java based client that doesn't have feature parity with Share (let alone Explorer).
A new Java based client would have guaranteed that all those customizations would have to be re-written from scratch.
In our opinion it feels like some people miss the point of Aikau. Often we field questions along the lines of:
As it was said on the Product Managers Office Hours last week; 'web technologies change every 3 years'. It’s probably even more often than that. In the short time that Share has existed there has been a constant changing of the guard for 'best web development framework'.
Even if we started again tomorrow with Angular (the current populist choice), we'd be doing so in the knowledge that there will be breaking changes when Angular version 2.0 is released next year and that in a few years we'll (allegedly) all be using Web Components anyway.
The long and short of it is that unless you're writing an application that is only going to have the lifespan of the carton of milk in your fridge then binding yourself to a single JavaScript library will be a mistake.
With Aikau we're trying to mitigate that problem through declarative page definition. Yes, you have to write a bit of AMD boilerplate but really the choice of JavaScript framework is entirely in your hands.
Aikau isn't tied to Share (theoretically it's not even tied to Surf) so if we do ever do switch to a new client then the existing widgets and your custom widgets will still be applicable. We’re also evaluating breaking Aikau out of the Share development life-cycle so that we can make new widgets and bug fixes available faster.
We've been talking about re-writing the Document Library using Aikau for a while now (and have a pretty good prototype already) along with the other site pages. However, just as the old header Component still exists in Share, the original pages will still remain so you'll always be able to configure Share to use the current YUI2 Document Library with your customizations.
There is also a lot of talk about re-writing the rest of Share in Aikau. Whilst we think this is ultimately a good idea we don't think it's worthwhile until we've gone to the trouble of evaluating and improving the current design.... do you really only want a carbon copy of the current Wiki, Blogs and Data List pages? We’ll get there in time, but we're not sure there’s any great rush to get this all done for 5.1.
Ultimately, any web interface needs to keep modifying its underlying technology. Aikau gives us a way to do that with the least possible pain. We understand that some developers have gone through some suffering with breaking changes in the last few releases, but through the use of Aikau we expect this pain to decrease and customisations to become more stable, transferable and powerful.
We’re working to add transparency to the development process that will hopefully make what we’re working on more obvious and make it easier for external developers to predict what changes there may be in future Share releases.
Introduction
Over the last 4 years (from versions 4.0 through to 5.0) there have been a number of changes in relation to Share development and customization.
From an outside perspective the decisions that have been made might appear confusing or frustrating depending upon your particular use case of Share. If you've written Share extensions or customizations for previous versions then you might have hit breaking changes between major releases and you might be fearful of it happening again.
It might seem that we don't care about these issues. We’re sorry if you have experienced such problems but we can assure you that we try our very best to move Share forwards without breaking what has gone before.
In this post we're going to highlight how things are better than they would have been if different decisions were made.
Decision #1 - Extensibility model
Back in 2010 we introduced an extensibility model that enabled us to dynamically change a default Share page via an extension module. This was an initially coarse customization approach that enabled Surf Components to be added, removed or replaced as well as our custom FreeMarker directives to be manipulated.
This in turn paved the way for us to refactor the Share WebScripts in 4.2 to remove the WebScript .head.ftl files and push the widget instantiation configuration into the JavaScript controller.
If we hadn't have taken this approach then the method of customization would still be copy and pasting of complete WebScript components to the 'web-extension' path.
This wouldn't have stopped breaking changes between versions (e.g. the REST API changing, the Component calling a different WebScript, different properties or URL arguments being passed, etc) and would have required constant manual maintenance of those WebScripts with code from service pack fixes as necessary.
Decision #2 - New Java based client
We know that a few customers still use heavily customised versions of Explorer and the fact that we've finally removed it from 5.0 is going to cause pain to a few.
It has been suggested at various points over the last 4 years that we could create a brand new client to replace Share - even though Share does not yet have complete feature parity with Explorer. We recognise now that we need to invest in Share and improve it over time since creating a new client would ultimately introduce more problems than it solves.
However, when calls were strongest for writing a new client, the recommendation was to move to either GWT or Vaadin. We're fairly sure all those people that lament the fact that this week we're not using Angular would be horrified if they were now stuck with a Java based client that doesn't have feature parity with Share (let alone Explorer).
A new Java based client would have guaranteed that all those customizations would have to be re-written from scratch.
Decision #3 - Aikau
In our opinion it feels like some people miss the point of Aikau. Often we field questions along the lines of:
- 'Why do we have to use Dojo?' (you don't)
- 'Why have you written your own JavaScript framework?' (we haven't)
- 'Why aren't you using Angular/Ember/React/Web Components?' (many good reasons; customization and configuration requirements, framework stability, performance etc.)
As it was said on the Product Managers Office Hours last week; 'web technologies change every 3 years'. It’s probably even more often than that. In the short time that Share has existed there has been a constant changing of the guard for 'best web development framework'.
Even if we started again tomorrow with Angular (the current populist choice), we'd be doing so in the knowledge that there will be breaking changes when Angular version 2.0 is released next year and that in a few years we'll (allegedly) all be using Web Components anyway.
The long and short of it is that unless you're writing an application that is only going to have the lifespan of the carton of milk in your fridge then binding yourself to a single JavaScript library will be a mistake.
With Aikau we're trying to mitigate that problem through declarative page definition. Yes, you have to write a bit of AMD boilerplate but really the choice of JavaScript framework is entirely in your hands.
Aikau isn't tied to Share (theoretically it's not even tied to Surf) so if we do ever do switch to a new client then the existing widgets and your custom widgets will still be applicable. We’re also evaluating breaking Aikau out of the Share development life-cycle so that we can make new widgets and bug fixes available faster.
Will there be more breaking changes?
We've been talking about re-writing the Document Library using Aikau for a while now (and have a pretty good prototype already) along with the other site pages. However, just as the old header Component still exists in Share, the original pages will still remain so you'll always be able to configure Share to use the current YUI2 Document Library with your customizations.
There is also a lot of talk about re-writing the rest of Share in Aikau. Whilst we think this is ultimately a good idea we don't think it's worthwhile until we've gone to the trouble of evaluating and improving the current design.... do you really only want a carbon copy of the current Wiki, Blogs and Data List pages? We’ll get there in time, but we're not sure there’s any great rush to get this all done for 5.1.
Summary
Ultimately, any web interface needs to keep modifying its underlying technology. Aikau gives us a way to do that with the least possible pain. We understand that some developers have gone through some suffering with breaking changes in the last few releases, but through the use of Aikau we expect this pain to decrease and customisations to become more stable, transferable and powerful.
We’re working to add transparency to the development process that will hopefully make what we’re working on more obvious and make it easier for external developers to predict what changes there may be in future Share releases.
Labels:
1 Comment
