Alfresco Tech Talk Live (Episode 70): Customizing Alfresco Share 4.2


Published on

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.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Alfresco Tech Talk Live (Episode 70): Customizing Alfresco Share 4.2

  1. 1. Share and Surf UI Updates Tech Talk Live - Dave Draper
  2. 2. Contents • Brief history • Why change? • Goals • What’s Changed • Examples
  3. 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. 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. 5. Goals • Make it faster to create new pages • Make it easier to customize pages • Improve re-use of code • Improve accessibility
  6. 6. Summary of Changes • Simple page creation • Dynamic dependency analysis in Surf • New widget library • New customization tools • CSS token substitution by Themes
  7. 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. 8. JavaScript HTML CSS i18n What is a Widget?
  9. 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. 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. 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. 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. 13. Demo
  14. 14. Why Dojo? • AMD • Accessibility • Widget templating • Unit testing
  15. 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. 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 •
  17. 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. 18. Demo
  19. 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. 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. 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. 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. 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. 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. 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 • • •
  26. 26. Demo
  27. 27. Screenshots
  28. 28. Example Pages • Page definitions NOT in Share 4.2 (but widgets are) • Kickstart Prototype • Document Library
  29. 29. Demo
  30. 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. 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. 32. Questions?