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). > > >> >>> 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? I described the use of it above. > > 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. This is not a bad idea at all and it's a very good compromise on a much more complex design I had to deal with time ranges. Let me think more about it, but for now I'm fine with what I have coded so far + adding a limit parameter to avoid the 10K tags rendering on the site-wide. Of course, besides the refactoring of the methods from the model to the pojo. Once I add the type-ahead Javascript to the edit UI I feel we have gotten most out of what we wanted for tags in this release. The only thing pending is really this optional business which I'd like to keep discussing. At the minimum, we would like an option to hide categories as much as possible from the admin UI and making sure that the APIs take categories and inserts them as tags instead. -Elias > > -- 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 >
