[wikka-community] table wikka_pages

[Masin Al-Dujaili]

Hello,

I just want to ask if the table wikka_pages will really have the handler column removed. As I stated earlier (about last year), there might be some use of it:

Category system:
Set handler to 'category' for data base entries in _pages, that should act as categories. Create an entry WikiPage with handler 'categories' for a list of categories 'page' WikiPage belongs to. Entry with handler 'page' is not touched. There should be a seperate edit handler for handler 'categories', displaying a simple text input field, a list of categories (WHERE ?handler? == ?CATEGORY? AND ?latest? == ?YES?, no further searching for string '{{category*').

Template system:
Template system means here: Putting together different types of data base entries like this for Page of type Template
%page%
::c::----
%category%
::c::----
Categories: %categories%

The template's page_tag corresponds to the entry in the field 'handler'. In templates, %(handler type)% refers to database entries with the same 'page_tag' as the requested one with different handlers. In the example above, Wikkawiki would load the body of WikiPage and use the show handler for 'page' on it, put the string in that's before %category%, then uses the show handler for 'category', again the string and finally the show handler for 'categories'. Afterwards, Wikkawiki would call the formatter.

Templates might even have different options than normal pages. If Wikkawiki displays a template, it could show options for editing and cloning. Cloning would create all the data base entries referred to in the template's body with the user specified page_tag.

Templates could even enable the user to have different views on the same set of data.

Authorization system:
User pages could have the handler 'user'. This would lift the restriction of user name's not equalling page names as both could coexist freely. More useful might be the handler 'group', where similar to 'categories' above the edit handler shows a list of users (and possibly other groups, but recursion should be avoided somehow) beneath a simple text input field.

Other uses:
I think, a PIM application in Wikkawiki can take advantage of this, if the handler can be set to 'calendar', 'contact', 'location', 'appointment', 'event', 'task', etc., each with its own distinct set of edit and show handlers.

Also, the handler could be used to manage media like images, sounds, movies and so on. There are many possibilities, the handler can be used for. It would great, if the ACL for a given WikiPage could differentiate between the different handler types, thus showing only partial content of a template, if the visitor is not allowed to view one of the database entries, e.g. 'groups' are shown only to members of the group or only to registered users, while the groups description (stored in groupname's page body) is available to everyone.

I really, really beg the devs not to drop this database field! Even if I cannot demonstrate any proof of concept right now, leaving the 'handler' where it is does no harm to Wikkawiki but dropping it disables any way of making some use of it. We don't need any of my suggestions in 1.1.7, maybe not even 1.1.8, but 1.2 might be a good perspective. Until then, we could tell Wikka to look for the page's handler in the directory stated by the field 'handler', that means removing the hardcoded directory lookup.

Best regards,
Masin



      __________________________________________________________
Gesendet von Yahoo! Mail.
Dem pfiffigeren Posteingang.
http://de.overview.mail.yahoo.com