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).
One other thing that we did was to push methods like getHotTags() out of
the model and into the domain model where it makes a little more sense.
Calling weblog.getHotTags() makes as much sense as calling
model.getHotTags(). If you look in the WebsiteData object you will see
there are already methods like getRecentComments() and
getRecentWeblogEntries() which are already doing this. So I think it's
better if we move your getTags() and getHotTags() methods from the page
model into the WebsiteData object.
Will do. Easy enough.
The site model is a different situation because it's not stateful and
simply provides access to data about the site as a whole. So putting
the getHotTags() method in here is fine.
Fine.
And I know I've said this a number of times now, but I still don't
remember getting an answer. How is the getTags() method supposed to
work given that it's completely unbounded? As I said before, that
method in the the SiteModel on a site like blogs.sun.com will end up
returning tens of thousands of results given time for tagging to take
hold. I'm sorry, but that's just not okay. I think that method needs
an offset and a length, and we need to define a max value allowed for
the length. Also, how is that result set meant to be ordered?
alphabetically? Maybe we should change it from the generic getTags() to
getRecentTags()?
WeblogManager.getTags() has a limit parameter I just didn't expose it in
the model but I can/will certainly do. The other approach is to use
offset/length but that's overkill for tagging. One more approach is to
use dates, but that forces us to use the big table and not the aggregate
table. Maybe we can do a switch in getTags() that if date is passed we
query the big table if those are null we use the aggregate table. I do
think that limit + order by count will return the most popular and we
can always include some sort of widgetry that using AJAX retrieves more
(I'm done with the type-ahead servlet). If we return ordered by count,
we would then just sort alphabetically and display the top 100 tags and
so forth. I hope this answers your question.
ummm, sort of. I am fine with the method just having a limit instead of
offset/limit, but I guess I am still confused about what the use of the
method is supposed to be. I understand the purpose of getHotTags(),
that one makes sense to me and I think we can leave it alone and just
restrict it to a reasonable size, like 100? However, I don't understand
why someone would want to call getTags()? How were you thinking this
method would be used?
about the date thing, maybe we can add a "lastUsed" column to the tagagg
table and that way you could do a getRecentTags() method directly
against the tagagg table.
-- Allen
-Elias
-- Allen
Elias Torres wrote:
I think I'm getting out of this tagging slump I was in and made more
progress on tagging. I've moved the WeblogManager code to use the
aggregate table now and everything is working fine. For now, I've
decided to go with the getAddedTags() and getRemovedTags() approach and
use the saveWeblogEntry and removeWeblogEntry methods in WeblogManager.
The idea behind this is that hopefully anybody manipulating a
WeblogEntryData POJO won't have to worry about maintaining the aggregate
table.
I've also added 2 macros to weblog.vm:
#showTagCloud($tags) and #showEntryTags($entry).
The first will get tags from the respective model (getTags() or
getHotTags(limit). The second will display tag links for technorati to
crawl.
I've also added support for filtering entries based on tags on the edit
UI and <drumroll/>
... I've tested tagging with unicode characters and everything worked
beautifully (once I made sure my db was utf-8).
Anyways, based on feedback, my next thing will be auto-complete servlet
which now should be very straight-forward.
-Elias
