Here are some Thoughts about the features "AREAS" and "PERSPECTIVES" as well as about the planned "NAMESPACES"
Table of contents
- is a feature to limit the visibility of any categorised content based on a set of categories and related perspectives.
Actually this feature "binds" a category and its content to a certain category. The so called "category jail" is used for this.
- All content which is categorised with one category of this specific set of categories will be visible just and only the allocated perspective.
- "AreaS" is an extention of "Perspectives"
- is a feature, that allows to override preferences. A perspective can be used to show the same content in different design or different structure, with different modules.
- "Perspectives" can be used to make up a personal desktop to see the default content of a website with individual modules and menus.
- "Perspectives" can be used to set up certain Spaces for workgroups.
- Combined with "Areas", "Perspectives" can be used to setup different individual public websites (or intranet-workgroups), where the links to categorised content always will be directed to the appropriate perspective.
- are a certain combination of "Categories" and "Perspectives", whilst the categories in the so called "Category Jail" are just limiting search results.
- in opposit to "Areas" the visibility of any content is not limited to a "Workspace/Perspective".
- Thus any content can be viewed in any Workspace once a link is known and the user has the appropriate permission.
Since we have "Areas" to limit visibility to certain "Perspectives", this behaviour of "Workspaces is a feature (and not a missing development or bug).
What is the problem?
- As Marc Laporte stated at dev.tiki.org/NameSpaces, it is not possible to use the same page name for a wikipage twice or several times.
- This would lead to the problem, that a workgroup could not use the simple common names "timesheet" or "eventplanning" etc. for a wikipage, if this name was "taken" by another workgroup before. This obviously would lead to a massive confusion after a while.
Just see the different used prefixes for translated pages on doc.tiki.org, if they have the same spelling in different languages.
What can or should Namespaces do?
- "Namespaces" would be a feature, that automatically adds a prefix or a suffix to a page (or to any content) when it is created.
This prefix (or suffix) would be faded out whilst the user "is in the Perspective".
- Being in another "Perspective" a link without prefix would either not work (not found error) or lead to another page with the same name, if one would exist in this "Perspective".
- From "outside" the "Namespace" related "Perspective" ... meaning from the "default website" or from another "Perspective" a link need to be extended by the "Namespace related prefix (or suffix)" to be directed to an appropriate page.
How that could work
- I suggest to extend the "Perspectives" feature with one or a few database table(s) and kind of a parsing script, that strips and extends the prefix/suffix of the actual "Perspective/Namespace" aswell on content-creation as on content-lookup.
- The lookup of this/these database table(s) must be limited to some conditions, not to extend the loading times of all content of a webssite/intranet
- Thus no lookup when default perspective and no prefix/suffix
- Only lookup to check if a content is existing in the active "Namespace/Perspective", if no prefix/suffix
- A given link with prefix/suffix needs no lookup, but just directing and stripping
I hope I could explain my thoughts understandable.
In my mind, "Namespaces" will make the "Workspaces" real "Workspaces".
The issue with the absence of "Namespaces" and the related problem of a lack of necessary naming flexibility seems to have been discussed frequently.
It was made clear to me first time by 'amette' at the TikiFestBLN2011.