Dan F schrieb:
> 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.
Okay, yours is better. But I will catch up...
But now that I'm sure that no harmful core changes are needed, I will
have to wait a bit to fix the remaining showstoppers for 1.3.8. If they
will disappear by testing... Sometimes they disappear automagically by
doing just nothing. I'm waiting for that :)
> 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
> 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'.
Well, we'll have to think of the user API to that. The only arg I have
is the optional "rating", you divided that into "ratingvalue" and
"ratingwidget", which I thought was overhead.
A value cannot be changed so this is fine for read-only lists:
fixed ratings, no recommendations. or other users recommendations which
the current users cannot change.
The widget can do everything, read-only and read-write. It can seperate
between rating and recommendations by using seperate colored smilies or
stars (like red and blue stars).
> 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
I think we already have this. The others are valid catches, I tried to
do keep it very simple for the beginning.
> 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?
To display the rating statistics for the current page. And to have short
link to that on every page.
avg rating, number of users, top N recommendations of various
relations, buddies, ...
> 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.
Seems to be cache issue. only CACHE=STRICT works ok now.
>> 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.
> 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.
Better make it an extra library, but don't touch WikiUser, please.
That's currently a very sensible topic.
>> 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
> Cool. I don't know how to do this, though. Remember, I'm new to Phpwiki!
> :-) (Also new to PHP actually.)
Very easy language, isn't it? I think I learned it in 4 days.
I'll do that later.
> 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.
That's the most complicated PhpWiki topic, besides the BlockParser.
I wonder where jeff got this from. But I think I get it slowly.
>> 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.
Well, we'll see. As long as every page needs to load the plugin, even at
section can access the plugin methods easily enough. So we need no
changes to other library parts and we need no extra library to maintain.
>> 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.
You only have to call the user-specific RateIt userinit code once, when
the user signs in. Then it's in a session variable.
You have to call getRating() and if empty getRecommendation() per page,
because that's page and user specific. But not the buddie list et al.
>> 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
> 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.
Hmm. A $dbi->touch should do the work also.
Cache problem explained:
select rating 4
=> request to /wiki/TestPage, with page internal request (by imgsrc) to
(random stuff to fool the client cache, to always update the click)
Problem: The client cache to /wiki/TestPage is not notified about the
change. The header should create a fresh etag for /wiki/TestPage or a
But we have empty args. The RateIt plugin is called by the theme
template, but we have no arg to notify the plugin what happened.
So RateIt doesn't know in the parent request, that the parallel imgsrc
request updated the page.
We could set a cookie or a session variable whenever that happens. Just
for this kind of request. But the parent will be too late to pick that
up. So we will need some kind of redirect. Bad bad.