incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Paige" <bobpa...@gmail.com>
Subject Re: page metadata again
Date Wed, 23 Jul 2008 12:43:00 GMT
I have a prototype of my metadata proposal implemented, and have run into a
snag.

My (erroneous) assumption was that by implementing preSave and preTranslate
filters I could encode the metadata without the user knowing. This is
certainly true for the scenario where the user enters some metadata, saves
the page, and views it. Unfortunately, the preTranslate filter is not called
prior to an edit so when the user edits a page after saving it they will see
the encoded metadata. I can write the encoding logic (in the preSave) filter
to handle this situation, but it is still messy in that the user is now
aware of my 'fiddling' behind the scenes.

I don't suppose there is some other mechanism that would allow me to decode
prior to an edit? Could I extend WikiEngine or PageManager to behave the way
I want, and insert my own instance into the server?

-- 
Bobman

On Mon, Jul 21, 2008 at 4:48 AM, Christophe Dupriez <
christophe.dupriez@poisoncentre.be> wrote:

> 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:bobpaige@gmail.com]
> To: jspwiki-user@incubator.apache.org
> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message