3. Aikau Basics
• Internally developed UI framework
• Designed for re-usability, customizability and
accessibility
• Initially part of Share, now an external GitHub project
• Used for:
+ Share header
+ Faceted search and faceted search management
+ Sites management
+ Custom Model Management (5.1 and 5.0 module)
+ Parts of Record Management
• Best unit test code-coverage of any Alfresco project
4. Hundreds of Modules
• 25 different form controls
• 20 different layout containers
• 20 different menu controls
• 44 different property renderers
• 8 variations of lists
+ 7 list views
+ 10 list view layout containers
• Document previewing
• Keyboard accessible drag-and-drop framework
• 30 different services
6. • Small Agile team
+ Supporting internal product feature development
• Public GitHub repository
• Use “GitFlow” process
+ Every Pull Request is code reviewed
• One week sprints
• Weekly backwards compatible releases
• Zero technical debt
+ Bugs prioritized over features
• Automated unit testing for regressions
+ Unit tests added for all new features
+ Unit tests add for all new bugs
7. Fast Turnaround
• Features and bugs not added mid-sprint
• Maximum wait of 2 weeks to turnaround a
bug or feature request
Sprint N+1
Bug Raised Added to Sprint Fix Delivered
Sprint N
One Week
9. Page Creation Basics
• An Aikau page is defined by a single WebScript
+ “Legacy” Share pages are defined by Surf Pages,
Templates, Regions, Components and WebScripts
• Pages are mapped using “URI Templates”
• Four templates are available out-of-the-box
+ “dp” (dynamic-page)
+ “hdp” (hybrid-dynamic-page)
+ “rp” (remote-page)
+ “hrp” (hybrid-remote-page)
• Recommended to use “dp”
• Custom templates can be defined
17. Customize…
• Existing pages via extension modules
+ Use the “Developer View”
• Create new or extend existing widgets
• Style through LESS variables in Theme
• Demo…
27. In General…
• Always feedback
+ Bugs, feature requests, requests for examples and
documentation, provide use cases, request extension
points, etc.
• Never copy and paste
+ Always extend or re-use
• Create composite widgets and libraries
• Use Services to access data
+ Normalize JSON response schemas
+ Avoid coupling widgets to data
• Use Pub/Sub or Events for communication
+ Avoid fixed references
29. “A widget doesn’t do what I want”
• Widgets are intentionally written to be easily
extendable
• Functions are small to encapsulate code that
might want to be changed
• Closures are generally avoided to make
functions available to be overridden or
extended
• Functions can be extended or overridden
+ Use this.inherited(arguments); to extend
32. Mix-In Modules
• Widgets support “multiple inheritance”
+ Widgets extend a primary module and then “mix-
in” additional modules
• “alfresco/core/Core” should be mixed-in
to all widgets
+ Provides core pub/sub and logging capabilities
• Abstract cross-cutting function to mix-in
modules
• Request abstraction of existing widget
code into a mix-in module
42. Breakpoints
• Logged error may not provide link to line
number
• Break on exceptions to zero in on error
conditions
• Need to include caught exceptions (Aikau
exceptions are caught)
• Need to typically skip past 3rd party
exceptions on page load
42