This deck was created by David Draper for Alfresco TTL 70 on October 2, 2013. It covers enhancements to the Spring Surf framework as used by Alfresco Share.

1. Share and Surf UI Updates
Tech Talk Live - Dave Draper

2. Contents
• Brief history
• Why change?
• Goals
• What’s Changed
• Examples

3. Brief History
• Alfresco Surf used in Share 3.0, 3.1 & 3.2
• Alfresco Surf becomes Spring Surf (first used in Share 3.4)
• Customization by copying and pasting WebScripts
• Initial extensibility features added in 4.0
• Introduced extension modules
• I18n properties, JavaScript controller and Freemarker template extensions
• Dynamic configuration added for 4.1
• WebScript refactor for Share 4.2
• Consistent boiler-plate with <@markup> directives
• Client-side widget instantiation logic moved from template to controller
• .head.ftl files deprecated

4. Why Change?
• YUI 2 is no longer being developed
• Creating pages in Share is too hard
• Accessibility
• Performance (reduce HTTP requests)
• Improve re-usability
• Improve extensibility

5. Goals
• Make it faster to create new pages
• Make it easier to customize pages
• Improve re-use of code
• Improve accessibility

6. Summary of Changes
• Simple page creation
• Dynamic dependency analysis in Surf
• New widget library
• New customization tools
• CSS token substitution by Themes

7. New Widget Library
• Over 100 new widgets
• Most widgets should be considered BETA (if not used in
default Share application)
• Consider them as guides or an indication of what is to come
• Strong inheritance
• Written with customisation in mind
• Documentation by JS Doc 3

8. JavaScript HTML
CSS i18n
What is a Widget?

9. Simple Page Creation
• Page creation by single WebScript
• Pages defined as a JSON model in JavaScript controller
• Freemarker templates just contain custom
<@processJsonModel> directive
• Use URI templates to load pages

10. Page templates
• Full page
• /share/page/dp/ws/{webscript URL}
• /share/page/site/{site}/dp/ws/{webscript URL}
• Hybrid page (content between header and footer)
• /share/page/site/{site}/hdp/ws/{webscript URL}
• /share/page/hdp/ws/{webscript URL}
• Hybrid remote page (definition loaded from Repository)
• /share/page/site/{site}/p/{page name}
• /share/page/hrp/p/{page name}

11. JSON Structure Example
The widget
to instantiate
The
instantiation
arguments
ID of the
definition in
the model
ID of the root
element in the
resulting DOM
Assigns to a
variable of the
enclosing widget
Used by the
enclosing
widget
Passed as an
argument
during
instantiation

12. Remote Pages
• Page definitions can be read from the Repository
• Currently targets hard-coded location that doesn’t exist
by default
• User permissions on API
• No executable code saved or run.

13. Demo

14. Why Dojo?
• AMD
• Accessibility
• Widget templating
• Unit testing

15. What is AMD?
“Asynchronous module definition (AMD) is a JavaScript API for defining modules such that the
module and its dependencies can be asynchronously loaded. It is useful in improving the
performance of websites by bypassing synchronous loading of modules along with the rest of
the site content.
In addition to loading multiple JavaScript files at runtime, AMD can be used during development
to keep JavaScript files encapsulated in many different files. This is similar to other
programming languages, for example java, which support keywords such as import, package,
and class for this purpose. It is then possible to concatenate and minify all the source JavaScript
into one small file used for production deployment.”
- Wikipedia

16. Dynamic Dependency Analysis
• Widgets become single atomic unit
• JavaScript (AMD and non-AMD)
• CSS
• HTML fragments
• Localization
• Configurable “analysis” beans in Surf
• Uses Regular Expressions to identify dependencies
• All dependencies pre-loaded into page
• http://blogs.alfresco.com/wp/developer/2013/03/05/under-the-hood-of-the-surf-updates/

17. Dependency Example
A B
C E
D
• Requesting A results in B, C, D & E being loaded
• C is only loaded once (despite being depended on twice)

18. Demo

19. NOT Just Dojo
• All widgets in the library start with the Dojo widget
template base
• Some widgets wrap existing Share YUI widgets
• Some new widgets use YUI resources
• Widgets exist that use other 3rd party libraries

20. NOT Just AMD
• Surf supports non-AMD dependencies
• It’s possible for a widget to declare a dependency on any
JavaScript resource
• Surf prevents duplicate resources being loaded multiple
times

21. Services and Widgets
• Services don’t (initially) contribute to the DOM but
respond to pub/sub events
• Navigation Service
• Action Service
• Logging Service
• Widgets contribute to the DOM but don’t (typically)
communicate with the server

22. Decoupled Communication
• Two methods of communication:
• Scoped pub/sub model (extends Dojo base)
• Custom event bubbling
• Separation of view and data
• Can extend services without extending widgets
• 3rd party widgets can use Alfresco services

23. Data Binding Registry
• Registry of data objects bound to callbacks
• A widget can register data for other widgets to bind to
• Allows automatic display updates

24. Where is this in Share 4.2 ?
• Currently just the new header bar
• New Document Library “parked” for the future
• Will potentially appear first in “Alfresco in the Cloud” before
Share 4.3

25. Customization Examples
• Three examples on the Alfresco Developer Blogs
• Convert “Admin” menu link to full drop-down
• Expand “Recent Sites” to access individual site pages
• Hiding “My Files” link
• http://blogs.alfresco.com/wp/developer/2013/09/04/customizing-the-share-header-menu-part-1/
• http://blogs.alfresco.com/wp/developer/2013/09/04/customizing-the-share-header-menu-part-2/
• http://blogs.alfresco.com/wp/developer/2013/09/16/customizing-the-share-header-part-3/

26. Demo

27. Screenshots

28. Example Pages
• Page definitions NOT in Share 4.2 (but widgets are)
• Kickstart Prototype
• Document Library

29. Demo

30. What Does This Mean For Me?
• Easier to build pages from existing Alfresco widget library
• Easier to create custom widgets by extending Alfresco
widgets

31. Future Possibilities
• Share will continue to be updated to use new widgets
• Easier to customise Share
• Easier integration of Community code
• Opens the door to new application creation

32. Questions?