Reini Urban wrote:
Dan F schrieb:
We did indeed change PageList a bunch, and I started changing
clients of PageList, e.g., AllPages, BackLinks plugin, etc. I attach
a few patch files (based on 1.3.7) just to show what we did. The
prior patch (about storing ratings) I felt pretty good about. On the
other hand, these patches are things we are still fundamentally
examining and reworking. Moreover, they may refer to files I've not
included that are still being worked on. However, perhaps it will be
helpful to see the type of stuff we are trying.
I think my solution (currently in CVS) is better. :)
Just one new PageList method.
No need for a contest. :-) I am happy with your changes in principle.
And thanks for your support in putting it in!
However, bugs or differences with our PageList that I found in the
version checked into the Phpwiki mainline:
1. Biggest thing: your change doesn't allow multiple users' ratings to
be displayed. At WikiLens, try putting "Buddies: DanFr, MikeCa" on your
user home page, then visit UserRatings. It'll display your ratings,
mine, and MikeCa's. This generalizes to many users. This was the comment
in PageList.patch about "one of the few possible ways to implement
variable numbers of same-type columns without altering the rest of the
code".
2. There are at least two types of things one might want on PageList:
+ rating value (the number, or possibly a non-clickable smiley
display. We use a number.)
+ rating widget (clickable smilies with cancel)
You added the widget only. We want the number as well, probably. Thus,
we had 'ratingvalue' and 'ratingwidget'.
3. The widget in PageList is not working for me. I changed the AllPages
plugin to have info=rating, and it is broken. Not sure why yet.
4. PageList with a 'rating' column is broken if you are signed out. In
our case, PageList protects itself, and the 'ratingwidget' column simply
is not added unless you are logged in.
5. The nowrap on the widget is gone (see the _format() function),
meaning the ratings widget might wrap (which looks bad). This has to be
on the table cell, so must be in PageList.
6. I added the possibility to put the pagename anywhere explicitly in
the 'info' arg. If the info arg doesn't have pagename, then it is added
on the end for backward compatibility. This allows more control over the UI.
Other RateIt bugs (not related to PageList):
7. The 'cancel' button didn't work for me. I had to set the dimension=0
by default in RateIt, then it worked.
8a. I do not understand the "RateIt" button. When you click on the
ratings it submits, so why have a button?
8b. Actually, when I click the "RateIt" button, it dissappears along
with the widget! Now it is gone from all pages. Where did it go? If I
sign out and back in, it comes back.
What about the Cancel as button? A big [X] or a trashcan (as in my
version)? Or text as in your version?
Eventually I think it should be an icon, like a trashcan or X. However,
I couldn't find the right icon. The picture you found doesn't look to me
like a trashcan when it's red. (It looks okay in grey.) On the plus
side, it has a tooltip (and shows up in browser bar). If I had to choose
between this particular trash can and "Cancel", I'd probably choose the
word, but I don't have strong feelings.
The "buddy" information is currently being parsed out of the user
home page. So for me to declare Reini a buddy, I put "Buddies:
ReiniUrban" somewhere on the "DanFr" page and log in as "DanFr."
This is one reason we really need 1.3.8, so we can have page
security for a user's home page. Also, the buddies stuff in general
(and user-group stuff) needs a lot of work, so as I am repeating ad
nauseum :-) this is not final by any means.
Aah, manual buddies! I originally thought of (probably offline)
user-clustering (with cluto) which will leed to automatic buddies. Ok,
fine.
cluto could make at least suggestions for buddies.
It is important to be able to choose one's buddies. :-) I agree, though,
that suggesting buddies is also a fun idea (which we've also had),
though not highest on my list.
But they have to be stored somewhere.
True. We've just been storing them in the user home page, but storing
them as user prefs might be better. Maybe not tho, see below. One nice
thing about the user home page is it's possible to have a linkable list
of buddies (see DanFr page on WikiLens).
Also, we are thinking that defining buddies is very similar to defining
groups. Thus, we'd like a "GroupLens" group by putting "Group
Participants: User1, User2, ..." on the GroupLens page, then be able to
compare ratings or get recs for GroupLens. This should be about the same
as putting "Buddies: User1, User2, ..." on the DanFr page and comparing
ratings or getting recs for DanFr's buddies (i.e., DanFr's group). This
might argue for keeping buddies in the Wiki page as they are now.
I thought of storing them as additonal SQL dimension
(dimension 1: user -> user relation), which would enable us to run
the recommendation engine on buddie relationships.
"Show current buddies", (only rated)
"Suggest new Top 5 buddies", (only unrated users)
"Suggest my Top 5 buddies" (rated merged with suggested TopN)
This would be a simple unweighted graph relation, perfect for suggest.
True. Fun, eh? Though that would be recommending buddies based on
friends-of-friends, which may not be useful (who knows? dating?). It
might be more fun to suggest buddies by interests you share (e.g.,
ratings). This ("finding neighborhoods") is a different algorithm from
getting recs. That's okay, tho. Plenty of fun.
But I still don't know how with which engine to handle weighted
relations (ratingvalues 0.5-5.0)
As we discussed, suggest currently has no weighted relations, though I
have emailed George to ask if he knows of and/or is willing to release a
version that does. Also, there's Cofi and MultiLens. The decision of
which rec engine to use is tricky, worthy of discussion. In my view,
none of them are perfect, pros and cons to each. One thing: open source
is better, then we can improve them.
I realized you'd also need the patch to WikiUser.php to see what's
going on. We were thinking about caching user ratings. Moreover,
there will probably be intersection and union of ratings, etc. You'll
say, "Whoa, don't change core WikiUser, make it a plugin!" Again, I
agree and I'm fine with that idea, but this is just the code we have
now, and I thought it might be useful for you to see where we are.
Hmm. Store plugin-specific extended preferences? This way they are
automatically transported in the session and saved in the homepage or
pref database.
But on RATING_STORAGE==SQL the user-specific ratings can be easily
extracted on session initialisation (login) from the rating database
instead of the pref db, even from within the plugin. (no core changes
needed)
Cool. I don't know how to do this, though. Remember, I'm new to Phpwiki!
:-) (Also new to PHP actually.)
Honestly, I don't understand PHP caching yet. We just thought if rating
and recs is truly fundamental, that wherever you had a user you might
want their ratings.
Same with RATING_STORAGE==WIKIPAGE, but then its stored in the same
place, the users homepage metadata.
So I would think they should NOT be stored as prefs, just in the session.
=> Just another private session variable. And no WikiUser methods.
Basically, code that wants any user's ratings has to ask the RateIt
plugin? Maybe a little awkward, but I'm fine with it.
Each plugin can easily detect auth[login]/auth[logout] and init its
session variable from its private STORAGE method then. No major
hackery needed.
I don't understand.
The only current problem I see is with the current imgsrc change on
click, which doesn't affect the original's page cache, though it should.
I might be forced to change this actionImg[imgsrc] scheme to call the
plugin directly as with the RateIt button and set the cache validators
manually.
I saw the whole 'cache validators' thing, but I just couldn't understand
it, so I ended up touch-ing the DB, and setting my cache policy to
STRICT. If you can make the cache validators work, that's great.
Thanks for your attention. This is fun.
Dan
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
|
