[pmwiki-users] Rating cookbooks (Peter Bowers)

john.rankin at affinity.co.nz john.rankin at affinity.co.nz
Wed Jan 28 00:42:37 CST 2009


> Date: Tue, 27 Jan 2009 17:54:18 +0100
> From: "Peter Bowers" <pbowers at pobox.com>
>> >   * {support} Great recipe. [[~John]] January 2, 2009 at 16:31 pm
>> >   * {oppose} Didn't work for me (PHP5 required). ~~~~
>> >   * {strong support} I love love love love L.O.V.E. it!!! :-x ~~~~
>>
>> We'd need to decide what the allowable items inside the parens
>> are, and how they would translate to an overall rating.
>> One disadvantage of this approach is that it isn't clear to
>> someone editing the page what the allowable terms inside the
>> parens are, and it's prone to spelling mistakes.
>
> ... I think a form-based system has way more advantages
> than disadvantages...
>
> ... having a code rather than words in the source of the page
> reduces the problem of what happens if someone does edit by hand
> ...
>
> * (+1) Great recipe. [[~John]] January 2, 2009
> * (-1) Didn't work for me (PHP5 required). January 3, 2009
> * {+2} I love love love love L.O.V.E. it!!! :-x, January 4, 2009
>
If I were implementing this, a first implementation would
record the minimum data and focus on user experience.
It would use a simple form:

Comment:
[....................................................................]
Author:      [..................................]
                    ( I am a fan of this recipe )

The form would include a hidden variable with value +1.

On submission, it would insert a line like this:

* (+1) <comment> [[~<author>]] yyyy-mm-dd

If author is blank, it inserts 'anon.' instead of the profile link.

If over time there is demand for a term to qualify the support
and people come up with a list of terms, this can be easily
added, and the form can map the term to a code. The +1
becomes "support". A markup rule could translate (<code>)
into text, but this is not needed yet.

JR





More information about the pmwiki-users mailing list