For the past several days I've been slowly but surely figuring out how
to emulate something that resembles the classic "Add to my favorites"
and "Remove from my favorites" links for wiki articles using semantic
data. After some long and quite spells at IRC #semanticmediawiki,
today I learned about this SF mailing list so I am polling you all to
find out if anybody recognizes the same (or similar) design goal and
can offer me some advice.

Overview:
I am planning for a collection of wiki articles describing "skins" for
each of several "boat" models. Those skinned boats are raced on
"tracks" which also have there own wiki articles describing each
track. So I will have:
3 categories of wiki articles: {Boats, Skins, Tracks}
3 templates: Template:Skin, Template:Boat, Template:Track
which are used, respectively,  by:
3 forms: Form:Skin, Form:Boat, Form:Track
all to facilitate the creating of each type of wiki article. That was
the easy part!

Each visitor to the wiki has their own personal favorites and would
like to bookmark/tag/record those favorites for later query.

    * The wiki hosting service is Wikia and they happen to have a 5
star article rating system which does seem to store each user's
personal 1..5 rating score for a page in a list ... however, that does
not appear to be linked in any way to semantic data or semantic
queries. (I am reasonably certain this is a dead end - but I mention
it just in case someone reading this knows better.)

My current best effort
So here's what I've been able to do with semantic data and later on
I'll describe where I get stuck. The core of my current best solution
is that each wiki article has obfuscated semantic data in the form of
a comma-delimited list of users who have marked that article as one of
ther favorite articles. (Am I going to run into some limit as to how
many strings can be in that comma delimited list?)

To manipulate that list of usernames, I define 3 properties:
Property:Favored by [[has type:string]]  (this will become the list of
users who have marked the current page as a favorite)
Property:This user [[has type:string]]
Property:Operation [[has type:string]] [[allows value::Add]] [[allows
value::Remove]]
and 1 template:
Template:Favorites
which is used by
Form:Favorites

Form:Favorites is a partial form designed to manipulate only the 3
properties listed above. Notice that all other content is hidden even
the Favored by list identified above. viz:

    {{{info|partial form|edit title=Manage your favorites}}}
    {{{for template|Favorites|label=Add/Remove this page to/from your
favorites}}}
    {{{field|Favoredby|hidden}}}
    {{{field|Thisuser|default=current user|hidden}}}
    ;Add or remove current user? : {{{field|Operation|radiobutton|
default=Remove|mandatory}}}
    {{{end template}}}

    {{{standard input|free text|hidden}}}

    {{{standard input|summary|preload=Form:Favorites/Preloads/
summary}}}
    {{{standard input|save|label=Confirm}}} {{{standard input|
cancel}}}


The first sticking point is this. Intuitively I'd prefer to be
specifying {{{field|Thisuser|preload=current user}}} rather than
default=current user but it seems that partial form with preload at
the field parameter level is not available by design.  I think this is
one great example where you really do want the existing value of This
user to be overwritten by the argument to a preload parameter. I think
my workaround for this is satisfactory (see below).

The second sticking point is that the radiobutton parameter is not
producing the expected toggling pair of radio buttons for user input.
With all other fields in Form:Favorites hidden/obfuscated this simple
Add/Remove binary choice should be the only decision a browsing user
is required to make.

A third (but minor) snafu is my use of |preload=Form:Favorites/
Preloads/summary
It just does not seem to be behaving as described at
http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Form_markup_language

Template:Favorites does the clever work of silently adding or removing
the current username to/from a comma-delimited list of usernames.
viz.

    {{#switch: {{#lc: {{{Operation|}}} }}
    | add      = {{#arraymap:{{{Favoredby|}}}|,|x|{{#set:Is a favorite
of=x}} }} {{#set:Is a favorite of={{{Thisuser|}}} }}
    | remove   = {{#arraymap:{{#replace:{{#arraymap:
{{{Favoredby|}}}|,|!|{{#switch:{{{Thisuser|}}}=|!}}}}|, ,|,}} |,|x|
{{#set:Is a favorite of=x}} }}
    | #default = {{#arraymap:{{{Favoredby|}}}|,|x|{{#set:Is a favorite
of=x}} }}</includeonly>
    }}
    {{#set:Operation={{{Operation|remove}}} }}
    {{#set:This user=}}


(If the http://www.mediawiki.org/wiki/Extension:ArrayExtension was
installed at Wikia then the above would be much more elegantly
implemented using #ArrayUnion: and #ArrayDiff:)

The aforementioned workaround that makes |default=current user
deliver what  |preload=current user  might have delivered is that very
last line that leaves This user with a null value. Without that null
value the |default=current user  parameter does not behave with the
preload effect that I wanted.

Finally, access to this partial form is created within Template:Skin,
Template:Boat, Template:Track via the line:

    [[Special:EditData/Favorites/{{PAGENAME}}|Manage your favorites]]


Where I need help
The above solution is functioning fine but it is singularly clumsy
that the user is presented with a text input box in which to type
either Add or Remove when a binary pair of radiobuttons is prescribed.
If someone can help me fix that anomaly then I'll be most grateful.
The above test case can be examined at http://smwtest.wikia.com/wiki/Form:Skin
however, I am working on it at the present time so the code you see
there may not reflect what you have just read above and of course, in
the weeks ahead, it may be erased altogether.

There may be a better way to implement this "Manage my favorites"
feature so if you have solved this problem differently then please
share it here.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Semantic Forms" group.
To post to this group, send email to semantic-forms@googlegroups.com
To unsubscribe from this group, send email to 
semantic-forms+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to