Allen Gilliland wrote: > > > Elias Torres wrote: >> Allen Gilliland wrote: >>> a few more little odds and ends ... >>> >>> 1. I'd prefer we not call the aggregate data "clouds". I think we can >>> find a better name that describes the data. >> >> +1 I have a bean called WeblogEntryTagAggData for aggregated data. I >> think you are right, since I think that cloud is not the only/future use >> of this table. >> >>> 2. Instead of updateTagSet() I think we should follow the getter/setter >>> bean pattern, so the method should be setTagSet() or possibly setTags() >>> because setTagSet() sounds weird? >> >> I'll move to setTags() and getTags() if possible (most likely), but >> setTags is used by hibernate to set the collection for the bean. I'm new >> to hibernate so if you have work-arounds or I'm simply wrong to think >> such a thing please let me know. That's why I'm using a different method >> for "updating" the tags, because I can't completely replace a reference >> to the internal set because hibernate throws up. Additionally, I don't >> want to lose the first time you used a specific tag because all we are >> currently sending to the client is the tag names. > > When I ran through my proof of concept version of tagging a while back I > used getTags() and setTags() without any problems. > > Also, looking at it I had a setTagsAsString() and getTagsAsString() > method which was useful for centralizing the task of bridging between > the XXXTag object and tag strings from the UI like "foo bar etc". May > be useful.
Those methods are useful and I already have them in the code. However, they are not in the pojo because I don't want to decide deep inside how we split the tags: commas or spaces. Maybe make that pluggable. > > >> >>> 3. I think the parameter for the feed url should be "tags" instead of >>> "tag" for consistency. >> >> I'll make a note of this. >> >>> 4. The PageModel is inherently constrained to a specific weblog, so >>> rather than getWebsiteTags() I think the method can be just getTags(). >>> But regardless of the naming I am still only okay with having this >>> method if it has some form of a constrained result set. >> >> >> Sure thing. >> >>> 5. I'm not sure I'm onboard for the tag search form thing. How is that >>> supposed to be used? >> >> Dave added that I believe. My TagServlet is for the edit-ui so you can >> have type-ahead of your own tags. I'm not really sure what Dave meant >> from it or maybe he was trying to interpret my messy proposal. > > I think we should talk a bit more about these last 2 items before you > commit to an implementation. I'd definitely like to hear more about the > purpose of the tag search form thing. > > About the type-ahead feature, I think that's an important feature and > something we definitely want to do, but I'm wondering if we should > consider a general architectural approach to ajax tools like this. Right > now we already have the UserData servlet which is a one-off of a similar > situation, and I'm sure we'll want to keep adding things like this, so > maybe we should organize this work a bit more so that we don't end up > with a huge assortment of one-off servlets for providing data to ajax > widgets? > > We could start by thinking about a consolidated url architecture where > all of these things operate under some kind of RESTful service stemming > from a single location. maybe ... > > /roller-ui/authoring/ajax/users (info about users) > /roller-ui/authoring/ajax/tags (info about tags) > etc, etc. > > or perhaps we can look at multi-purposing Jeff's AAPP stuff? the only > danger there is that there are security implications since the AAPP > stuff has the ability to modify data. > > -- Allen > > We need to have this discussion. >> >> -Elias >> >>> -- Allen >>> >>> >>> Elias Torres wrote: >>>> Thanks Dave! The page is much more readable now. >>>> >>>> I have updated the page with answers to most of your todo's. Regarding >>>> my progress I now have edit-ui for tags, tags tab in frontpage, hot >>>> tags >>>> in sidebar. From a code perspective this means, pojos, weblogmanager, >>>> sitemodel and struts together with .vm/.jsp changes are done. >>>> >>>> Things to do: >>>> >>>> - entries for specific tags (and their pagers) >>>> - feeds >>>> - type-ahead servlet >>>> - parameterize the tags tab in frontpage >>>> - .. and code thread to optimize the aggregation for large sites (i.e. >>>> pre-compute tagclouds) >>>> >>>> Any more feedback on the proposal? Should I email asking for a vote? >>>> >>>> -Elias >>>> >>>> Dave wrote: >>>>> Oops. Here's the link: >>>>> <http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_WeblogTags> >>>>> >>>>> - Dave >>>>> >>>>> >>>>> >>>>> On 9/18/06, Dave <[EMAIL PROTECTED]> wrote: >>>>>> I review the tagging proposal and (with Elias' permission) >>>>>> reformatted >>>>>> it for readbililty. I also added some comments and a couple of TODO >>>>>> and ISSUE markers to indicate places that need clarification. >>>>>> >>>>>> Please review and provide feedback. How close are we to agreement on >>>>>> this proposal? >>>>>> >>>>>> - Dave >>>>>> >>>>>> >>>>>> >>>>>> On 9/18/06, Dave <[EMAIL PROTECTED]> wrote: >>>>>>> On 9/15/06, Elias Torres <[EMAIL PROTECTED]> wrote: >>>>>>>> I have begun writing some of the tagging support for Roller 3.1 >>>>>>>> and I >>>>>>>> have a basic unit working. I've created WeblogEntryTagData and >>>>>>>> added >>>>>>>> methods to WeblogEntryData to support Tagging. I've also written 10 >>>>>>>> tests in WeblogEntryTest.java and of course added support in the >>>>>> editing >>>>>>>> UI to manage tags. >>>>>>> Personally, I'd like to see a complete proposal before work >>>>>>> begins -- >>>>>>> i.e. a list of the specific methods w/signatures that will be >>>>>>> added to >>>>>>> the managers and page models, a list of the macros that will be >>>>>>> required, etc. Listing those page models and macros could reveal >>>>>>> some >>>>>>> data model deficiencies. >>>>>>> >>>>>>> That said, I'm not opposed to committing partial work as long as we >>>>>>> have consensus on the proposal (I think we do) and there is a >>>>>>> commitment to finish it. >>>>>>> >>>>>>> BUT... Please wait until I create a Roller 3.0 release branch >>>>>>> from the >>>>>>> trunk today (I just reviewed the changes since RC1 and the >>>>>>> non-sandbox >>>>>>> ones look good for 3.0). >>>>>>> >>>>>>> - Dave >>>>>>> >
