Wiki source for TypedPages


Show raw source

=====Typed Pages=====
The basic idea is to have a selection box during page creation where the user decides how the page content should be interpreted. The page types are simply templates how data has to be entered respectively displayed. This way you could make use of WikkaWiki as a generic database interface (with limitations, of course) where you could store different but recurring data types. It might be useful for:
~-item lists and character lists for RPGs
~-personal presentation
~-biographies and discographies
~-galleries
~-calendars
~-task schedulers
~-forums (and bulletin boards and guestbooks)
~-bug tracker
~-blogs (and diaries)
~-web mailer

Even if a lot of the above might be accomplished using actions or just mere Wiki syntax, it might not be the most elegant way of doing this. Basically, the data of the page content is used to fill fields in the page type template. The template might be in Wiki syntax, making it easy to maintain as a wiki page, or a raw HTML file. In both cases there's need for facilities to enter only once the template commands for recurring data.

====Data fields====
In the template data fields could be adressed using the ##""::(identifier)""## markup (alt. ##""::(%identifier%)""##). In the wiki page content the data is stored as
%%
::(first name)Masin::
::(last name)Al-Dujaili::
::(gender)m::
::(birth date)1977-02-17::
%%

===Generic fields===
I haven't looked at the wikka tables closely but I guess there are some database fields already defined ;-). At least ##content## I remember having seen. In the context of data fields for page typing, every data field ##content## is stored in the database field ##content## besides any other data fields. Every template should have the generic data field ##content##. Additionally we might define fields like ##user## and ##timestamp## but these are probably already in the database. Perhaps someone with more experience in data organisation should have a look at this.

===Forum data fields===
A forum might be realized using a template with these data fields:
%%
::(%inreplyto%)::
::(%title%)::
::(%author%)::
::(%timestamp%)::
::(%content%)::
::(%followup%)::
%%
These data fields could even be defined more precisely:
%%
::(%inreplyto%)%parent_read_only%::
::(%title%)re: %parent%::
::(%author%)%current_user%::
::(%timestamp%)%automatic%::
::(%content%)%parent%::
::(%followup%)%children%::
%%
Of course the key words or macros would have to be defined somewhere. And it could be done more elegant or more simple. Maybe someone wants to share her ideas concerning this.

====Type Templates====
===Template Names===
There should be a naming convention for type templates. Currently all pages ending in 'Template' are recognized as templates which some actions use for a different behaviour. I'd suppose to use 'TTemplate' for backwards compatibility, the first 'T' meaning simply 'Type'.

====Working with Typed Pages====
===Creating===
When creating a page, the first step would be to decide which type the page is. A simple dropdown list of all pages ending with 'TTemplate' might be sufficient but not too descriptive. Part of any TTemplate should be something like ##::(pagetype)This is the display name of the page type::##. One backdraw might be, that any page creation process is accompanied by a lot of database queries -- might not be too performant. On the other hand: The extension LinkUsingPageTitle does something quite similar. Considering this, one question arises: Why not use a header for the TTemplate display name? Because it might be used for display of the typed page content.

After choosing the desired type, the page either dynamically reloads with the current selection or just displays a link 'Continue'.

===Editing===
Editing should work just as used to. Wikka displays a page with all fields valid for the current page type.

===Altering===
Don't know if it's of any use, but it could even be possible to alter the page type after creation. In case of an alteration from a page type other than 'Wiki page' to 'Wiki page' it just displays it's page content with all the colon markup (see above). Page alteration should be highly tolerant, thus altering a calendar page to a forum page (why ever!) should preserve as much as possible, e.g. all unknown markup should be dropped to the ##content## field, a field generic to all templates and //always// visible (at least during page type alteration). Thus a user might cut&paste the data to its destination fields.

===Storing Typed Pages===
All typed pages should be stored with their page type at the beginning. We could alter the Wikka database to have a field ##pagetype##, though.

====Example Usages====
===Meta Pages===
//November, 29th.// The last few days I thought about some kind of usage, I did not think of before. When I went to bed in my mind there were URLs like
~-HomePage/acls
~-RecentChanges/category
~-""UserPage""/edit
and I knew, that those kind of stuff could be realized very simple as TypedPages. In fact, in the database there should be for any page meta pages containing meta content about this page. As I'm talking about TypedPages here, I thought of ""EditTTemplate"" as
%%
::(PageTypeTemplate)Template for edit page::
{{edit page="::(%pagebody%)%page2edit.body%"}}
{{nocomments}}
%%

""{{edit}}"" would just be an action defaulting to the page it is stored on and providing the display of an edit box, a field for edit comments and the required buttons. The page ""UserPage""/edit should only be readable by those who have write access to ""UserPage"".

Similarly, ACLs could be stored using ""AclTTemplate"". Access to this page should only be possible for admins and the page owner.

%%
::(PageTypeTemplate)Template for Wikka Acces Control Lists (ACLs)::
::(%read_acl_label%)$texfield::
::(%write_acl_label%)$texfield::
::(%comment_acl_label%)$texfield::
{{nocomments}}
%%

Using this, it would result in a normal Wiki page (just a Typed Page) HomePage/acls containing

%%
::AclTTemplate::
::(read_acl_label)*::
::(write_acl_label)+
!RestrictedUsersGroup::
::(comment_acl_label)+::
{{nocomments}}
%%

Categories might be the most interesting way of usage. But also the most difficult to implement. As demanded on CategorySystemOverhaul, any new system should allow at least the same flexibility as the current system but should be more careful with resources and such. Implementing the category system as kind of a meta information system might be the way for doing this. In this idea, Wikka stores category information in a page of its own for each non-meta page, e.g. RecentChanges/category which would like:

%%
::CategoryTTemplate::
::(category[0])Maintenance::
::(category[1])Metacontent::
::(category[2])Wiki::
{{nocomments}}
%%

The Template would be

%%
::(PageTypeTemplate)Category selection template::
::(%category[]%)%list_of_categories%*::
{{nocomments}}
%%

##category[]## indicates an array of values, while ##%list_of_categories%*## indicates multiple choices. As you can clearly see, I'm no computer scientist that invents some new grammar out of nowhere :-).

**The main advantage of using TypedPages for meta-content is the traceability of changes using just normal and already existing Wikka pages. If RecentChanges had some filter abilities, any user could simply select which changes to have displayed. Dropping handlers for such operations has the other advantage that users, admins, whoever might be able to simply include or exclude information on the pages currently generated by handlers, e.g. edit pages could get some basic formatting help, while ACLs pages won't display ACL syntax thingies.**

to be continued
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki