Revision history for TypedPages

Revision [18992]

Last edited on 2008-01-28 00:13:29 by MasinAlDujaili [Modified links pointing to docs server]

No Differences

Revision [15718]

Edited on 2006-11-29 07:15:30 by MasinAlDujaili [more and more]
====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%"}}
""{{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)::
Using this, it would result in a normal Wiki page (just a Typed Page) HomePage/acls containing
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:
The Template would be
::(PageTypeTemplate)Category selection template::
##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.**

Revision [15398]

Edited on 2006-10-05 10:42:26 by MasinAlDujaili [continued (but still not finished)]
===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.
====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====
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 should work just as used to. Wikka displays a page with all fields valid for the current page type.
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.

Revision [15396]

Edited on 2006-10-05 06:12:49 by MasinAlDujaili [continued (but not finished)]
===Forum data fields===
A forum might be realized using a template with these data fields:
These data fields could even be defined more precisely:
::(%title%)re: %parent%::
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.

Revision [15395]

The oldest known version of this page was created on 2006-10-05 06:00:29 by MasinAlDujaili [continued (but not finished)]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki