Hi Bob!
Interesting discussion and proposals!
I would like to emphazize the need of page structures associated with page
types.
One may think that what I want is a data base, not a Wiki: it is partly true, I
would like to combine important advantages of a data base with those of a Wiki.
Some applications examples:
* Application parameterisation: Imagine that paragraphs (groups of lines)
within a .properties becomes a Wiki page. The documentation would be integrated
within the page and parameter values could be field values of a WikiForm.
Here the pages could be replaced when a newer version of the application
would be installed BUT the data in the fields would be stored separately. The
user would see a dynamic merge between a Form and metadata values.
Goodbye awful XML files for application parameters!
So for me, a page type would be a template containing a Form where page
(meta)data is merged automatically to produce the page presented to the user.
There would be to display mode (separate template?): one "read only" and
another one "edit mode"
* Encyclopedia: pages of a given category (type) would require a name, a
translated name in english, synonyms, antonyms, grammatical characteristics and
a definition. Those could be edited through fields in a form to guarantee that
the structure is respected
* Any kind of directory: names, structured information and the
description/definition (with Wikitext)
Personnaly, I like the idea of "Namespace" where projects and types are
represented in a hierarchy of prefixes to page name (your option 2).
As I said before, the only thing needed and beneficial anyway, is a "beefed up"
rename function to rename a whole hierarchy of page. For instance, rename
XXXXX.{*} to YYYYY.{1}
So, my personal proposal:
(metadataX indicates any name for a metadata field, valueX the corresponding
value)
project.type.page contains [{SET metadata1='value1'}][{SET
metadata2='value2'}]...
project.TEMPLATES.type.DEFAULT contains default values for metadata: [{SET
metadata1='value1'}][{SET metadata2='value2'}]...
project.TEMPLATES.type.DISPLAY contains a display template where ${metadataX}
indicates where the different metadata fields are inserted. One may want to be
able to indicate conditional labels appearing only when metadataX exists.
Something like ${metadataX?text if metadataX exists:text if metadataX does not
exist} could do the trick.
project.TEMPLATES.type.EDIT would contain an edit form where fields are
metadata fields that will be stored.
With some moral support (and critics/suggestions!) of the community, I may
implement this... or help anyone involved.
Christophe Dupriez
Centre Antipoisons-Antigifcentrum
C/o Hôpital Central de la Base Reine Astrid
Rue Bruyn
1120 Bruxelles
Belgique
tel 32-(0)2.264.96.36
fax 32-(0)2.264.96.46
----- Original Message -----
From: Bob Paige [mailto:[EMAIL PROTECTED]
To: [email protected]
Subject: page metadata again
> I have another thought on metadata within a page. I know this doesn't meet
> all of Murray's requirements (mine are simpler) but I think it could still
> work. The reason I am sharing it here is to see if anyone can point out
> holes I don't see yet.
>
> My requirements are these:
> 1. organize pages by project
> 2. organize pages by type within a project
> 3. make it easy for people to create new pages
>
> As I've shared in previous emails, I dislike the workflow of requiring a
> user to edit the Project page to add a static link to a non-existent page
> just to create a new page. My preference would be that the user view the
> Project page and have it automatically (through Tags or
> ReferringPagesPlugin) dynamically discover all pages related to this
> project. The catch is how to establish this linkage in a way that is not
> fragile.
>
> Option 1: Back-links.
>
> Create a page 'Project1'. On that page use ReferringPagesPlugin to find all
> pages pointing to it that also end in some keyword (i.e. 'Spec' for
> specifications).
>
> Create another page ('my Spec') with a back-link to 'Project1'.
>
> Benefits:
> * by using different name suffixes you can have many categories of pages
> automatically linked to the project page.
>
> Drawbacks:
> * Any page that references Project1 and ends in 'Spec' (even one that really
> belongs to 'Project2') appear in the list for Project1.
>
>
> Option 2: Back-links with page name prefixes
>
> Create a page 'Project1'. On that page use ReferringPagesPlugin but only
> display pages whose name starts with 'Project1' and end with 'Spec'.
>
> Create another page ('Project1 My New Spec').
>
> Benefits:
> * many categories of pages as in option 1
> * only displays pages that actually belong to Project1 (fixes drawback of
> option 1)
>
> Drawbacks:
> * fragility; if we rename the Project1 page all the back-links to it are
> renamed, but the arguments passed to ReferringPagesPlugin are not updated
> and the prefixes on all the related pages are not updated.
>
>
> Nothing really new here; this is the same thing Murray said in the past when
> I suggested using naming conventions for tying pages together.
>
>
> Option 3: Use page-level meta data
>
> This is the holy grail in that it provides page-level information that ties
> things together even if the pages are renamed. Murray has his Tags plugin
> but it has some limitations (i.e. it indexes the pages itself and doesn't
> persist the index).
>
> What I am proposing here (assuming you've read this far) is a way to include
> page-level meta data that is automatically indexed by whatever
> SearchProvider you use (Lucene, Basic, or whatever).
>
> My proposed solution is this:
>
> Using a plugin (or even a CSS style; the important thing is to encapsulate
> your meta-data in something), you insert meta-data into the page, i.e.:
>
> [{Metadata Type=Spec Project=Project1}]
>
> Next (and this is the hackish part) you write a pre-save filter that
> rewrites the metadata tags as something like this:
>
> [{Metadata qwertydvorakType=Spec qwertydvorakProject=Project1}]
>
> The SearchProvider will index this.
>
> Finally, you write a pre-translate filter that converts it back to the
> original text entered by the user.
>
> Now all you need is another plugin that searches for pages using the hackish
> prefixes. The key to making this solution work is the hackish prefix on the
> metadata. It is indexable and searchable by the standard SearchProvider and
> invisible to the user.
>
> So that's my story. The only drawbacks I see are:
> 1. looks hackish
> 2. metadata is embedded within the page instead of separate
>
> What do you think?
>
> --
> Bobman
>
