Tiki is already one of the most feature-rich social business/web content management platforms that exist today, with all of these features being shipped in an "all-in-one" package, which makes it all the more impressive. Throughout its history, hundreds of developers have contributed directly to its codebase.
Nevertheless, in Tiki 14, the Tiki Addons feature was added to allow a way for thousands of developers to add an even broader range of functionality that can be used with Tiki.
http://dev.tiki.org/Addons
2. Background
¨ It all started with Tiki Profiles
¨ We have a way to quickly install preferences and
Tiki objects – great!
¨ Some issues faced:
¤ Too much work to write profiles from scratch, but we
can now export profiles – great!
¤ Profiles useful for “demos” but so far not so good for
“ready to use” features – why?
3. “Ready to use” features
¨ Needs configurable preferences
¤ Variations of use cases (without forking profiles)
¨ Needs custom templates (and custom CSS), e.g.
¤ Pretty tracker templates
¤ List/CustomSearch plugin templates
¤ Activity stream/notification templates
¨ Needs versioning and dependency management
¤ Able to systematically install, upgrade, remove
¤ Able to specify what else is installed first
4. Demo
¨ Event calendar version 0.1
¨ Someone installs it
¨ Now added new field in the tracker, and added
preferences to make some fields optional, released
as version 0.2
¨ Let’s upgrade from version 0.1 to 0.2
5. Do Tiki addons support code?
¨ Views (thinking of changing name as it seems potentially confusing)
¤ Think of it as a wiki-plugin but it executes specifically
through the Addon wiki-plugin
¤ Pretty much the same except it has its own namespace
¤ Views can also execute as a module
¨ Libs
¤ Introduced through standard (relatively new) Tiki
custom.xml style dependency injection
¤ e.g. a custom AJAX service or lib used by views
6. What is the Addons API in Tiki?
¨ To make sure that things that affect Tiki directly are
part of Tiki itself (avoid Drupal problem)
¤ To reduce duplication
¤ To make it easier for other add-ons to use “core-type”
functionality without reinventing the wheel
¤ E.g. Organic Groups API: The concept of organic groups is
core functionality but each addon is different
¤ E.g. Navbar API: Every addon might need a nav bar, but
every nav bar is different
¤ E.g. File Gallery API: Every addon might need its own File
Galleries - makes sense to have standard way to use them
7. Best practices
¨ Addons should be more about profiles and
templates than they are about code
¨ Component features should be in Tiki core and not
addons
¨ A good addon should interface to Tiki in
predictable ways (limit breakage on refactor)
¤ Addon APIs
¤ Directly extending classes in systematic, limited way
¤ Make limited direct calls to legacy Tiki functions
8. Why GITHUB?
¨ Distributed responsibilities need distributed
development environments
¨ Easy to fork and merge back from various forks
¤ Encourage innovation through variants of each addon
But need (currently missing) Tiki Addons directory
¤ Centralized hub, easily searchable, feedback/rating
¨ But need git-svn (unless other solution exists) sync
¤ Calculated in community commit stats
9. Potential (App store concept)
¨ The vision is to have one day an “app-store” of
different “ready-to-use” features that can be
installed à Expand user base
¨ Expand developer/power-user community
¤ Casual developers/power-users do not ever need to
touch Tiki core code if they are doing just profile +
template based addons
¤ More serious coders are encouraged to contribute to
Tiki core (in the Addons API and also in the lib/core/…
e.g. lib/core/Services)
10. Possible Tiki addons
¨ Knowledge repositories
¨ CRM / ERP
¨ Shopping carts
¨ Project management apps
¨ Social networking apps
¨ Activity streams
¨ Organic Groups
¨ Search UI
¨ Integration with 3rd party apps
¤ some key open source software can be integrated within Tiki
but of course impossible to have too many in core
11. What’s missing
¨ Tiki Addons directory
¤ Easily searchable
¤ Feedback and rating
¤ Code itself can be on GITHUB but linked here
¨ More developer documentation
¤ Improve existing
¤ More examples
¤ More webinars
12. What’s missing
¨ Display installed addons to users by default
somewhere
¤ Link to the specified homepage for each addon?
¨ Addons installer needs to record preferences
changed by addons
¤ Intelligently warn conflicts
¨ Expand pref. name limit to beyond 40 characters
¨ Non-console admin panel way to install addons