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? > > 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. -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 >
