Dave Levy wrote:
tagagg should have date created and date last used so getNewtags can be
written at some time. Ideally the user that first creates a tag should
be recorded on the tagagg row, so we build a show innovators query
create tagagg (name, datecreated, dateused, firstuser, timesused )
timesused = select count(*) from tags where name = $myname This is a
deoptimisation
select firstuser, name
from tagagg
where datecreated > now - $period
and timesused > $interesting_threshold
I'm not sure I understand the usefulness of these. Why do you want to
see the popular tags that you happened to be the first to use? Most
tags are going to be reused over and over again, so who cares who was
the first one to use the tag "java" or "glassfish"? It seems to me that
having that info would not give you any insight into something of value.
I think the same goes for datecreated. What is the purpose of knowing
when the first time a tag was used? Think one year down the line, will
there be any reason do know that someone first used the tag "java" 11
months, 8 days, and 14 hours ago? Technically that data will be stored,
since we capture a date element on the tag reference itself, but I don't
think we need it in the aggregate data.
-- Allen
This doesn't have to be done for the next release.
I sort my mail most recent first and I have been on the road for the
last two weeks so there may have been some discussions
I missed and my comments are out of place. If so, sorry.
Elias Torres wrote:
Allen Gilliland wrote:
Elias Torres wrote:
Allen Gilliland wrote:
Elias Torres wrote:
Allen Gilliland wrote:
Elias Torres wrote:
Allen Gilliland wrote:
On a slightly separate note, one other thing we need to think more
about
is the model methods. Just like macros we want to keep those as
trimmed
and clean as possible.
In general the models like page and feed which are stateful and
represent a request should provide methods to get at the data from
that
request. So I think for these models the getTags() method should
return
the set of tags specified by the request, and null if no tags were
specified.
I'm not sure I understand what does: "set of tags specified by the
request". Could you please clarify a bit more?
meaning that when someone requests the url /weblog/tags/foo+bar or
/weblog/feed/entries/rss?tags=foo+bar then the output of
$model.getTags() should be the 2 EntryTagData objects for "foo" and
"bar". this follows the existing pattern where getLocale() or
getCategory() will return the value that is being used to render the
content (i.e. as specified by the request).
getTags() returns just the tag name and the tag count. I don't
want to
use the tags specified in the request. getTags() is what we feed into
the #showTagCloud macro to render. The difference between
getHotTags()
and getTags() is the sortBy method and the limit. In getHotTags() we
only want 10,20,50. In getTags() we want them all (at least for a
blog).
Enter the limit parameter. If the site-wide tag cloud is too big
we can
restrict it to the top 100 and use a slider to get 300, 1000 via a
url
parameter or AJAX if needed (Note: your idea below of a lastUsed
would
be a much better tie-breaker when fetching top XXX instead of
alphabetical sorting).
well, I think it's very important that you provide a method in the
stateful models like pageModel & FeedModel that they have a method
that
returns the tags which are part of the weblog request, and by
convention
that method should be named getTags(). I don't care if you return the
TagAggData object instead of the EntryTagData object.
I see what you mean now. Just a method for accessing the request tags.
I still don't understand what you intend to do with a tag cloud which
has hundreds or thousands of tags, that seems absurdly large to
me. So
I am still not okay with having a way for users to get *all* of their
tags. Look at most sites like flickr.com/tags/ or
technorati.com/tags/
or del.icio.us/tag/, none of them offer tag clouds of more than 150ish
tags.
I didn't say I wanted all tags for a site-wide. Maybe I have mistakenly
said so somewhere else.
I wasn't actually being specific for site-wide vs. weblog, I think the
issue holds for both cases.
"If the site-wide tag cloud is too big we can restrict it to the top
100
and use a slider to get 300, 1000 ..."
I am still thinking ... 300? 1000? Where do you see tag clouds that
big? Why do people need tag clouds that big?
You are right that 1000 is WAY overkill, but see my comment below.
This m
We must remember the "long tail" (I can't believe I said that).
I don't know what that means :/
It's just the fact that sometimes more people are interested in looking
for different tags less popular as opposed to a whole bunch of people
looking for the same tags always.
http://en.wikipedia.org/wiki/Long_tail
I said a *weblog* would most likely need all of its tags for entry
navigation and I doubt that would get to 10,000 or more. But sure, we
can/should limit that (at least parameterize it with a default).
Why would it need all of its tags? I think we are fully justified in
setting a maximum value for the number of tags which get returned to
users. If you are really concerned about what this value would be then
make it configurable, so that it can default to something like 150 but
be changed to 1000 if someone thinks that's okay.
In any case, despite this issue over an imposed limit on the result set
size of querying for tags, I am also still of the opinion that it
doesn't really make sense to have a method called getTags() for a
site/weblog. I was thinking about this a bit more and I think that it
would be totally fine if we only had a getHotTags() method which returns
the XXX tags with the highest counts. Then to give users a little more
freedom I suggest we try adding in that "lastUsed" column to the tagagg
table so we can track dates and then have a getHotTags(sinceDays) method
which would let users get their hottest tags in the last XX days.
IMO that covers the majority of scenarios where I think users are going
to want to get their tag data and make clouds.
Agreed. I'll get back to work. Thanks for all your
feedback/dialogue/suggestions/evil comments/etc. I like the Roller team.
-- Allen
-- Allen
