History: Areas

            ! Areas

^New __experimental__ feature in ((Tiki8)).
Visit tiki-admin.php?page=areas
This feature --__will be taken out__ of Tiki before the 9.2 release and __be replaced by a concept of building up Areas with a custom module__ "perspective_autoswitch" which is explained furtheron on this page.-- has been revamped for ((Tiki10)) and ((Tiki11)).
See [http://dev.tiki.org/Areas+Perspective+Multi-domain+dogfood|here] for ongoing development notes.^

Just recently the Areas as Feature and the file binderlib.php (originally tiki-perspectivebinder.php) turned out to be a dead end.
At the TikiFestBarcelona3 (August 2012) Luci and Torsten figured out a completely different way to generate Areas. On a Website that uses "Perspectives", Areas can be build with ''===a custom module using some smarty syntax and wiki syntax===''.

__Explanation:__

1) Areas is NOT a feature (any more) 
2) Areas is a concept of structuring and setting up the navigation through out a website.
3) An Area is kind of a __Spaces__ on a website. Areas divide the site into several subspaces with individual modules, menus and content which are "bend" together with categories.

On a website that does not use the feature "Perspectives", it is mainly possible to build "Areas" only with modules and theme control, which should be more easy in Tiki 10, since tere it is possible to limit and exclude module visibility to/from subtrees of categories.

If "Perspectives are used, the "Areas" will have to use the "Perspective" feature.
On a "Perspective" or "Workspaces" using Website it is quite easy to build Areas on Top of Workspaces, as a Workspace is just "converted into a "defined Area" by binding together the default category of the "Workspace" with the allocated "Perspective".

This can be done with a custom module and some smarty code, where we include some "Smarty" syntax.

Here is an example of the content of such a custom module, which I recommend to call it

''"perspective_autoswitch"''

The plugin "perspective_autoswitch" should be assigned to the "pagetop" and get the parameter "nobox=y" to make it invisible.

{CODE()}
{if isset($objectCategoryIds) and in_array(1, $objectCategoryIds)}
{wiki}{literal}{REDIRECT(perspective=1) /}{/literal}{/wiki}
{elseif isset($objectCategoryIds) and in_array(2, $objectCategoryIds)}
{wiki}{literal}{REDIRECT(perspective=2) /}{/literal}{/wiki}
{elseif isset($objectCategoryIds) and in_array(7, $objectCategoryIds)}
{wiki}{literal}{REDIRECT(perspective=3) /}{/literal}{/wiki}
{elseif isset($objectCategoryIds) and in_array(9, $objectCategoryIds)}
{wiki}{literal}{REDIRECT(perspective=4) /}{/literal}{/wiki}
{elseif isset($objectCategoryIds) and in_array(10, $objectCategoryIds)}
{wiki}{literal}{REDIRECT(perspective=5) /}{/literal}{/wiki}
{elseif isset($objectCategoryIds) and in_array(11, $objectCategoryIds)}
{wiki}{literal}{REDIRECT(perspective=6) /}{/literal}{/wiki}
{elseif isset($objectCategoryIds) and in_array(12, $objectCategoryIds)}
{wiki}{literal}{REDIRECT(perspective=7) /}{/literal}{/wiki}
{/if}
{CODE}

__Hints:__

*The preference "Categories used in Templates" __must__ be activated to get the module working (-+tiki-admin.php?page=category+-).
*To not unnecessarily extend the server load I suggest to assign the module specifically only to the affected categories.
*In each affected category the Redirect Plugin has to be approved once it gets loaded or you can approve the plugin at -+tiki-plugins.php+-.

Maybe we will develop a solid default module later on.