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:
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 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
Comments [Hide comments]
Comment by BrianKoontz
2006-10-05 09:55:02
Great idea! I'm a big believer in the use of a wiki as a framework (much as someone might use CakePHP or any number of frameworks). So many things are already taken care of for you -- authentication, session handling, basic CSS layout -- that it makes no sense to re-invent this functionality each time you need a quick-and-dirty DB interface, or blog, or whatever. I design entire course curricula on my wiki, then export everything with a custom HTML handler that localizes links, scrubs CamelWords, removes headers/footers, etc. What do I get for my efforts? Clean HTML documents that just work.

I've been toying around with an idea for a quick-and-dirty form generator that would allow (authorized) users to quickly create forms that would automagically link up with pre-existing tables and fields with no SQL and a minimal syntax. Data validation and scrubbing would be handled by the wiki, all the user would have to do is specify the form parameters and the fields to be linked to.
Comment by DarTar
2006-10-05 11:54:38
I'm also happy that you opened this discussion - I have a couple of similar ideas that I'll post soon on this page.
Comment by DomBonj
2006-12-02 19:46:21
I discovered this thread just after posting the StructDataAction, which was designed along similar lines of thought (adding typed 'structured data items' to any page). Introducing types and mixing unstructured and structured content to the wiki while preserving simplicity and security is a promising development.
Comment by DarTar
2006-12-03 04:26:41
Hi DomBonj, I agree these two proposals might easily become part of a common framework. Thanks for your code contribution, I look forward to giving it a try.
Comment by MasinAlDujaili
2006-12-05 07:12:26
I just stumbled over Smarty (http://smarty.php.net/). It seems similar to what I intend on doing with TypedPages. Maybe you want to take a look at it. It looks quite powerful with most the features needed for TypedPages. As far as I've looked through its features, it might well be able to replace some formatters.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki