Nooku Framework

Joomla 1.6

Nooku Framework runs on Joomla 1.6. No reported issues.

WordPress

Work on getting Koowa to run on WordPress have started. Both the plugin and the framework are loading. Work is continuing to run the harbour3 example. The following is a overview of issues that have been encountered and possible solutions.

Coupling Issues

1. Rendering CSS and JS in the page header

WordPress is using an action and filter system. Actions are similar to Joomla/Nooku event while filters are similar to Nooku commands.

To render the header of a page WordPress is using the wp_head, wp_print_styles, wp_print_scripts and wp_meta action. These actions will need to be mapped to a custom KDocument adapter for WordPress to allow Nooku to push the relevant page header information to the WP framework.

More info :

• http://codex.wordpress.org/Plugin_API
• http://codex.wordpress.org/Plugin_API/Action_Reference
• http://adambrown.info/p/wp_hooks

Note : For consistency a similar approach could be taken for Joomla. KDocument could act as a bridge between Nooku and third party systems it is being run in.

2. Handling redirects

At the moment Nooku is passing off responsibility for redirects to Joomla using it's KDecoratorJoomlaApplication. It would be easier if redirects in Nooku Framework itself.

One problem we're having is that WP is using page_id instead of ItemID for menu links. So redirects are currently having the same effect on WP, as if you redirected to index.php on Joomla.

4. JRoute

JRoute is a crucial part in any extension. It not only does the work of creating SEO optimized URLs, but more importantly append the ItemID variable in URLs as needed.

JRoute are also used with redirects, so to get redirects right, we need to make a bridge to whatever WP uses. And also make the same bridge to JRoute for consistency so that this is handled by the framework.

5. JText

Nooku Framework is still relying on JText, in order for it to be able to work standalone a solution should be implemented that removes the coupling to JText and at the same time allows to plug-in different translation solutions. A proposed approach could be to choose for a strategy pattern implementation.

6. JUtility

PHP Fatal error: Class 'JUtility' not found in /trunk/code/plugins/system/koowa/template/filter/form.php on line 40

The form filter is relying on JUtility to get a token. Coupling should be removed and a solution implemented so that each system can define it's own token renderer.

7. JFilterOutput

PHP Fatal error: Class 'JFilterOutput' not found in /trunk/code/plugins/system/koowa/template/helper/select.php on line 138

The template helpers are still coupled in various places to the Joomla Framework. All template helpers should be refactored to run fully stand-alone.

8. JPATH_* constants

All JPATH* constants should be replaced by their KPATH* counterparts and set in the plugin to make them system independent.

9. JToolbar

Koowa are currently capable of rendering the toolbar on its own. But loads it to the "toolbar" module position by default in order to be more native to the Joomla 1.5 back-end UI. The toolbar needs a refactor, getting rid of the tables and rendering it in the extension view by default, instead of in a module position. So that it's more portable.

References to Joomla! found in libraries/koowa

In case you want to use Nooku Framework outside of Joomla!. This is work in progress.

Last update Nov.3, 2010:

occurrences of JText::_(), JRoute::_() and JUtility::getToken()

Other references to the Joomla!-framework:

• JText::sprintf() is used in KDatabaseBehaviorLockable.

• KControllerView::getRedirect(): the way an url is made with index.php?option=com_etc. Idem in KTemplateHelperGrid::_createURL()

• KDatabaseAdapterAbstract::_initialize(): jos_ is appended as standard db-prefix to the config-array

• KLoaderAdapterComponent::_setBasePath() uses JPATH_ADMINISTRATOR and JPATH_SITE in case applicationname is "admin" or "site". Same naming convention as Joomla! for component folders etc. Idem in KLoaderAdapterModule and KLoaderAdapterPlugin. Those two also uses JPATH_BASE.

• KTemplateHelperBehavior assumes that Mootools is in the same folders as used in Joomla!

Of course KFactoryAdapterJoomla refers to JFactory; no problem. Idem KLoaderAdapterJoomla (uses JLoader).

com_default: is a default Joomla!-component using Nooku Framework; so no problem that it has references to the Joomla! Framework. But: in the KTemplateFilter factory:
$identifier = 'com.default.template.filter.'.trim($identifier);