incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Dupriez" <>
Subject Re: page metadata again
Date Mon, 21 Jul 2008 08:48:16 GMT
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

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)  contains  [{SET metadata1='value1'}][{SET metadata2='value2'}]...
project.TEMPLATES.type.DEFAULT contains default values for metadata: [{SET metadata1='value1'}][{SET
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
tel 32-(0)
fax 32-(0)

----- Original Message -----
From: Bob Paige []
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

View raw message