Re: Tag questions Was: Couple of proposals for 4.0
On 3/9/07, Henri Yandell <[EMAIL PROTECTED]> wrote: On 3/8/07, Elias Torres <[EMAIL PROTECTED]> wrote: Apologies for asking this when the latest trunk does have tags - I can only see my 4.0-dev box at home (and I've not figured out how to make the frontpage work on trunk there yet). BTW, Roller 3.1 will be the first release to support tags. When I enter tags, I see that it offers me tag-completion. Is that shared between blogs? I just did a little test and determined that no, tag-completion only considers the tags in your blog. Is there a theme that supports tags yet? No and we decided to leave out a tags macro too. Here's what I use to display the tags cloud on my blog: #set($mytags = $model.weblog.getPopularTags(-1, 100)) #foreach ($tag in $mytags) #if ($tag.count > 4) $tag.name #end #end - Dave
Re: Couple of proposals for 4.0
Carrie Yandell wrote: > On 3/9/07, Allen Gilliland <[EMAIL PROTECTED]> wrote: [snip] > I haven't played with tags yet though, and am looking forward to that > for solving some other things I grumble about :) As for aggregation, > will have to H to explain that one to me because I don't understand > that at all! Nah. No need for Henri to explain. I think you are ready to be nominated for commit access! :D Just in kidding. On a serious note, I think planets is what you need. Basically every author gets their own blog and their tag each posts with multiple tags according to their target aggregated blog. Then you build a planet for each audience you want and it fetches items from all of the authors with the proper tag. For example, you can write an entry with tags 'son','knitting'. Then have two planets one for family and one for knitting. That post then would be *shared* on both blogs without us having to overload the db and application with unnecessary overhead. I hope this helps. -Elias > > Thanks for listening, > Carrie >
Re: Couple of proposals for 4.0
On 3/9/07, Allen Gilliland <[EMAIL PROTECTED]> wrote: I'm not sure that those links really convinced me that this is highly sought after feature for blogs, but I can certainly see how it would be useful in certain situations and ultimately I have no problem with adding it in. So I am +1 to the idea if you want to do it. Well mostly those links only showed to myself I'm not the only one who thinks it's useful :) I wasn't sure since no one else had seemed to request it! For example, why can't you just have a single blog but use categories or tags to allow people to see entries from specific topics? And alternatively, as a few folks have suggested, you could still have multiple blogs but use the aggregation tool to merge the content between them together when appropriate. I can understand this might be messy. It's only something I thought of the other day so no worries if it's not feasible. I did want to explain, however, that having a single blog wouldn't work for me. After all our "family" blog (where we talk about our son mostly for the benefit of our families) has multiple authors and I just don't want multiple authors on my personal blog. And if I ever did host one of those "knitalongs" I wouldn't want all those people to have access to my blog either! Equally I don't think many family members want to slog through my relatively boring posts about knitting :) These are not sophisticated computer users and it's a lot easier for them to go to a single web address for Nathan's blog than a complicated one that sorts through categories or tags at my blog. I haven't played with tags yet though, and am looking forward to that for solving some other things I grumble about :) As for aggregation, will have to H to explain that one to me because I don't understand that at all! Thanks for listening, Carrie
Re: Couple of proposals for 4.0
Carrie Yandell wrote: I would like to expand on Hen's requests with some explanation about why I think these features would be a good addition to Roller. RE: *1* Sticky entries. User is able to make a blog remain at the top of their HTML (though not their RSS). The order of multiple sticky entries would remain by date. I've seen "sticky posts" several times on other blogs, and I have been harping on Hen to make it happen for me for the past few years for the following reasons: 1) I basically blog for two reasons. Mostly it's "note to self" type stuff. However I also post longer entries where I seek feedback, comments, and opinions. These posts are more "important" as far as community is concerned. I also tend to post a fair bit, so what bugs me about my blog is that my "important" entries fall off the bottom fairly quickly. I think it would be great to be able to "pin" some of my entries to the top so that I could catch a few more comments if possible, particularly for those who check my blog only rarely as opposed to using a feeder. 2) Another scenario involves the blog community I'm most involved with -- knitting. There are blogs called "knitalongs" where everyone is working on the same project. One blog will have multiple authors. They post progress on their own projects and questions to other knitters on these blogs. Frequently with knitting, errata will be posted, and this is usually posted at the top of the blog. GREAT usage of sticky posts in my opinion! I did a quick google search and turns out I'm not the only one seeking sticky posts: http://www.stephanspencer.com/archives/2006/02/26/blog-seo-tip-6-make-sticky-posts/ http://labnol.blogspot.com/2006/09/blogging-tricks-how-to-make-sticky.html http://blog.blogware.com/help/index.html?stickyposts.htm http://blogger-tricks.blogspot.com/search/label/sticky%20post Okay so most of these illustrate hacks for getting a post to stay "sticky". The point is it's a useful feature and a feature that people are seeking. I'm not sure that those links really convinced me that this is highly sought after feature for blogs, but I can certainly see how it would be useful in certain situations and ultimately I have no problem with adding it in. So I am +1 to the idea if you want to do it. RE: *2* Shareable posts. The ability for a user to post to more than one blog at a time. Rather than copying them, I think what we'd do is have the blog entry be authored for one blog, but then have the ability for the author (or another author on that blog) to share them with other blogs My rational for this is simple: I maintain two blogs and sometimes they overlap. It would be easier to have a mechanism whereby I could post this on both blogs rather than going through the steps to copy, past and publish it on my other blog as well. Roller itself encourages people to author more than one blog on the Main Menu page: "Feel like you've got more to say? Maybe another weblog is what you need." Okay so I have two blogs -- one for my crafty (and personal) endeavors and one for our son that Hen also contributes to. Back to the knitting world (and the Mommy Blog world does this too, but I won't go there), this is incredibly common. Lots of folks have one blog for whatever their passion (and community) is, and one for personal stuff. And sometimes even a third expressly for their kids. The problem is my two blogs are starting to overlap, especially as Nathan gets old enough for craft stuff. So more and more often I'm contemplating where to post something when it really goes on both. Again with the knitting blogs, you see the sentence "cross-posted at my whatever blog" quite a lot. Especially with the knitalongs -- people want a record not only at the knitalong blog, but also at their personal blog. You see the same post both places. Wouldn't it be nice and easy to be able to just post both at the same time? I haven't seen this feature anywhere, but I think it's a great idea. And maybe it would be a good thing to have some unique features. The problem with this feature is that it's a bit messy when it comes to information architecture and you are probably better off updating your blog organization rather than trying to cross post things all over the place. So instead of having 2 (or more) blogs and cross posting the overlapping entries, why not have 1 blog and use filters to provide the equivalent of the multiple blogs you used to have? For example, why can't you just have a single blog but use categories or tags to allow people to see entries from specific topics? And alternatively, as a few folks have suggested, you could still have multiple blogs but use the aggregation tool to merge the content between them together when appropriate. -- Allen Carrie Yandell On 3/8/07, James M Snell <[EMAIL PROTECTED]> wrote: Dave wrote: > [snip] > I consider that a bug. The standard front-page theme should support > pinned-to-main, which
Re: Couple of proposals for 4.0
I would like to expand on Hen's requests with some explanation about why I think these features would be a good addition to Roller. RE: *1* Sticky entries. User is able to make a blog remain at the top of their HTML (though not their RSS). The order of multiple sticky entries would remain by date. I've seen "sticky posts" several times on other blogs, and I have been harping on Hen to make it happen for me for the past few years for the following reasons: 1) I basically blog for two reasons. Mostly it's "note to self" type stuff. However I also post longer entries where I seek feedback, comments, and opinions. These posts are more "important" as far as community is concerned. I also tend to post a fair bit, so what bugs me about my blog is that my "important" entries fall off the bottom fairly quickly. I think it would be great to be able to "pin" some of my entries to the top so that I could catch a few more comments if possible, particularly for those who check my blog only rarely as opposed to using a feeder. 2) Another scenario involves the blog community I'm most involved with -- knitting. There are blogs called "knitalongs" where everyone is working on the same project. One blog will have multiple authors. They post progress on their own projects and questions to other knitters on these blogs. Frequently with knitting, errata will be posted, and this is usually posted at the top of the blog. GREAT usage of sticky posts in my opinion! I did a quick google search and turns out I'm not the only one seeking sticky posts: http://www.stephanspencer.com/archives/2006/02/26/blog-seo-tip-6-make-sticky-posts/ http://labnol.blogspot.com/2006/09/blogging-tricks-how-to-make-sticky.html http://blog.blogware.com/help/index.html?stickyposts.htm http://blogger-tricks.blogspot.com/search/label/sticky%20post Okay so most of these illustrate hacks for getting a post to stay "sticky". The point is it's a useful feature and a feature that people are seeking. RE: *2* Shareable posts. The ability for a user to post to more than one blog at a time. Rather than copying them, I think what we'd do is have the blog entry be authored for one blog, but then have the ability for the author (or another author on that blog) to share them with other blogs My rational for this is simple: I maintain two blogs and sometimes they overlap. It would be easier to have a mechanism whereby I could post this on both blogs rather than going through the steps to copy, past and publish it on my other blog as well. Roller itself encourages people to author more than one blog on the Main Menu page: "Feel like you've got more to say? Maybe another weblog is what you need." Okay so I have two blogs -- one for my crafty (and personal) endeavors and one for our son that Hen also contributes to. Back to the knitting world (and the Mommy Blog world does this too, but I won't go there), this is incredibly common. Lots of folks have one blog for whatever their passion (and community) is, and one for personal stuff. And sometimes even a third expressly for their kids. The problem is my two blogs are starting to overlap, especially as Nathan gets old enough for craft stuff. So more and more often I'm contemplating where to post something when it really goes on both. Again with the knitting blogs, you see the sentence "cross-posted at my whatever blog" quite a lot. Especially with the knitalongs -- people want a record not only at the knitalong blog, but also at their personal blog. You see the same post both places. Wouldn't it be nice and easy to be able to just post both at the same time? I haven't seen this feature anywhere, but I think it's a great idea. And maybe it would be a good thing to have some unique features. Carrie Yandell On 3/8/07, James M Snell <[EMAIL PROTECTED]> wrote: Dave wrote: > [snip] > I consider that a bug. The standard front-page theme should support > pinned-to-main, which is a Global-Admin only way to pin a blog entry > to the front-page of a Roller site. > > I think adding a "pinned" option for make good sense. > As a general FYI, I'm taking a slightly different tact with pinned entries "Pinned to main" entries in our updated internal blogs will show up as popup notices on the front page separate from the other entries. They will be used to inform users of planned outages, etc and will be listed separately from the other entries. Among our user base of several thousand bloggers, I haven't heard of any one clammering for the ability to pin posts to the tops of their own blog pages. > >> *2* Shareable posts. The ability for a user to post to more than one >> blog at a time. Rather than copying them, I think what we'd do is have >> the blog entry be authored for one blog, but then have the ability for >> the author (or another author on that blog) to share them with other >> blogs. I'm unsure whether the permissions should be: >> >> i) An author can share to any blog that they have write permissi
Tag questions Was: Couple of proposals for 4.0
On 3/8/07, Elias Torres <[EMAIL PROTECTED]> wrote: Henri Yandell wrote: > On 3/8/07, Elias Torres <[EMAIL PROTECTED]> wrote: >> >> >> Henri Yandell wrote: >> > >> > So maybe this is "we should allow multiple categories for a blog >> entry"? >> >> You can use tags. We have feeds based on tags and we support multiple of >> those. I'm also working on search feeds. > > I've been meaning to ask - are categories automatically tags in your setup? We disabled categories altogether. Redundant. > > How do people share their tag dictionaries with each other? We have a tagcloud. But no "tag dictionary" per se. Apologies for asking this when the latest trunk does have tags - I can only see my 4.0-dev box at home (and I've not figured out how to make the frontpage work on trunk there yet). When I enter tags, I see that it offers me tag-completion. Is that shared between blogs? Is there a theme that supports tags yet? Hen
Re: Couple of proposals for 4.0
Henri Yandell wrote: > On 3/8/07, Elias Torres <[EMAIL PROTECTED]> wrote: >> >> >> Henri Yandell wrote: >> > On 3/8/07, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> >> >> >> >> [snip] >> > >> > So maybe this is "we should allow multiple categories for a blog >> entry"? >> >> You can use tags. We have feeds based on tags and we support multiple of >> those. I'm also working on search feeds. > > I've been meaning to ask - are categories automatically tags in your setup? We disabled categories altogether. Redundant. > > How do people share their tag dictionaries with each other? We have a tagcloud. But no "tag dictionary" per se. -Elias > > Hen >
Re: Couple of proposals for 4.0
On 3/8/07, Elias Torres <[EMAIL PROTECTED]> wrote: Henri Yandell wrote: > On 3/8/07, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> >> [snip] > > So maybe this is "we should allow multiple categories for a blog entry"? You can use tags. We have feeds based on tags and we support multiple of those. I'm also working on search feeds. I've been meaning to ask - are categories automatically tags in your setup? How do people share their tag dictionaries with each other? Hen
Re: Couple of proposals for 4.0
Henri Yandell wrote: > On 3/8/07, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> >> [snip] > > So maybe this is "we should allow multiple categories for a blog entry"? You can use tags. We have feeds based on tags and we support multiple of those. I'm also working on search feeds. -Elias > > Hen >
Re: Couple of proposals for 4.0
On 3/8/07, Allen Gilliland <[EMAIL PROTECTED]> wrote: James M Snell wrote: > Dave wrote: >> [snip] >> I consider that a bug. The standard front-page theme should support >> pinned-to-main, which is a Global-Admin only way to pin a blog entry >> to the front-page of a Roller site. >> >> I think adding a "pinned" option for make good sense. >> > > As a general FYI, I'm taking a slightly different tact with pinned > entries "Pinned to main" entries in our updated internal blogs will > show up as popup notices on the front page separate from the other > entries. They will be used to inform users of planned outages, etc and > will be listed separately from the other entries. Among our user base > of several thousand bloggers, I haven't heard of any one clammering for > the ability to pin posts to the tops of their own blog pages. I agree that "pinned to main" is a bad description of that feature and we can probably do better, plus it should be built into the default frontpage theme. I also agree with James that this is not likely to be a feature that normal blogs would really benefit from as evidenced by the fact that AFAIK nobody has asked for it yet. I would probably defer to what other major blog software is doing for the final decision though, do MovableType and WordPress offer this? Apparantly other blog engines do do this, but we'll (family) need to look around to figure out which ones. I know it's been Carrie's #1 requested feature for the last 3 years :) >>> *2* Shareable posts. The ability for a user to post to more than one >>> blog at a time. Rather than copying them, I think what we'd do is have >>> the blog entry be authored for one blog, but then have the ability for >>> the author (or another author on that blog) to share them with other >>> blogs. I'm unsure whether the permissions should be: >>> >>> i) An author can share to any blog that they have write permissions to. >>> ii) An author can share to any blog that is set up as able to share to >>> in the blog's permissions (regardless of permissions). >>> iii) Both of the above; ie) configure the blogs you can share to AND >>> need perms. >> Sounds kind of complicated. You'd do that via many-to-many >> relationship between weblogs and entries? Can't we solve that problem >> with aggregation instead? >> > > Sounds really complicated to me and not really all that useful. Planet > aggregation seems like a much better / more elegant approach. I agree, an aggregation is a nicer way of solving this problem in a whole variety of ways. I'm probably not up to date on how to do the aggregation. Ive been meaning to ask if there are any docs for getting up and running with Roller's Planet. My understanding of this feature is that it's for when a user has multiple blogs and they wish to post to both blogs at the same time. Doing that via aggregation seems very painful. I could see how someone could have one blog with multiple categories (and then subcategories) and treat each category as its own blog visually. Then if we supported a blog entry being in more than one category it could be shared. So maybe this is "we should allow multiple categories for a blog entry"? Hen
Re: Couple of proposals for 4.0
James M Snell wrote: Dave wrote: [snip] I consider that a bug. The standard front-page theme should support pinned-to-main, which is a Global-Admin only way to pin a blog entry to the front-page of a Roller site. I think adding a "pinned" option for make good sense. As a general FYI, I'm taking a slightly different tact with pinned entries "Pinned to main" entries in our updated internal blogs will show up as popup notices on the front page separate from the other entries. They will be used to inform users of planned outages, etc and will be listed separately from the other entries. Among our user base of several thousand bloggers, I haven't heard of any one clammering for the ability to pin posts to the tops of their own blog pages. I agree that "pinned to main" is a bad description of that feature and we can probably do better, plus it should be built into the default frontpage theme. I also agree with James that this is not likely to be a feature that normal blogs would really benefit from as evidenced by the fact that AFAIK nobody has asked for it yet. I would probably defer to what other major blog software is doing for the final decision though, do MovableType and WordPress offer this? *2* Shareable posts. The ability for a user to post to more than one blog at a time. Rather than copying them, I think what we'd do is have the blog entry be authored for one blog, but then have the ability for the author (or another author on that blog) to share them with other blogs. I'm unsure whether the permissions should be: i) An author can share to any blog that they have write permissions to. ii) An author can share to any blog that is set up as able to share to in the blog's permissions (regardless of permissions). iii) Both of the above; ie) configure the blogs you can share to AND need perms. Sounds kind of complicated. You'd do that via many-to-many relationship between weblogs and entries? Can't we solve that problem with aggregation instead? Sounds really complicated to me and not really all that useful. Planet aggregation seems like a much better / more elegant approach. I agree, an aggregation is a nicer way of solving this problem in a whole variety of ways. -- Allen - James
Re: Couple of proposals for 4.0
Dave wrote: > [snip] > I consider that a bug. The standard front-page theme should support > pinned-to-main, which is a Global-Admin only way to pin a blog entry > to the front-page of a Roller site. > > I think adding a "pinned" option for make good sense. > As a general FYI, I'm taking a slightly different tact with pinned entries "Pinned to main" entries in our updated internal blogs will show up as popup notices on the front page separate from the other entries. They will be used to inform users of planned outages, etc and will be listed separately from the other entries. Among our user base of several thousand bloggers, I haven't heard of any one clammering for the ability to pin posts to the tops of their own blog pages. > >> *2* Shareable posts. The ability for a user to post to more than one >> blog at a time. Rather than copying them, I think what we'd do is have >> the blog entry be authored for one blog, but then have the ability for >> the author (or another author on that blog) to share them with other >> blogs. I'm unsure whether the permissions should be: >> >> i) An author can share to any blog that they have write permissions to. >> ii) An author can share to any blog that is set up as able to share to >> in the blog's permissions (regardless of permissions). >> iii) Both of the above; ie) configure the blogs you can share to AND >> need perms. > > Sounds kind of complicated. You'd do that via many-to-many > relationship between weblogs and entries? Can't we solve that problem > with aggregation instead? > Sounds really complicated to me and not really all that useful. Planet aggregation seems like a much better / more elegant approach. - James
Re: Couple of proposals for 4.0
On 3/8/07, Henri Yandell <[EMAIL PROTECTED]> wrote: Small things, but I wanted to see what people thought. *1* Sticky entries. User is able to make a blog remain at the top of their HTML (though not their RSS). The order of multiple sticky entries would remain by date. I'm never sure what Pinned to Main means, I think it pins it to the planet-like blog on the front page? It doesn't seem to do the above and there's nothing on the standard blog install now that seems to match the javadoc description of: "True if story should be pinned to the top of the Roller site main blog." I consider that a bug. The standard front-page theme should support pinned-to-main, which is a Global-Admin only way to pin a blog entry to the front-page of a Roller site. I think adding a "pinned" option for make good sense. *2* Shareable posts. The ability for a user to post to more than one blog at a time. Rather than copying them, I think what we'd do is have the blog entry be authored for one blog, but then have the ability for the author (or another author on that blog) to share them with other blogs. I'm unsure whether the permissions should be: i) An author can share to any blog that they have write permissions to. ii) An author can share to any blog that is set up as able to share to in the blog's permissions (regardless of permissions). iii) Both of the above; ie) configure the blogs you can share to AND need perms. Sounds kind of complicated. You'd do that via many-to-many relationship between weblogs and entries? Can't we solve that problem with aggregation instead? - Dave
Couple of proposals for 4.0
Small things, but I wanted to see what people thought. *1* Sticky entries. User is able to make a blog remain at the top of their HTML (though not their RSS). The order of multiple sticky entries would remain by date. I'm never sure what Pinned to Main means, I think it pins it to the planet-like blog on the front page? It doesn't seem to do the above and there's nothing on the standard blog install now that seems to match the javadoc description of: "True if story should be pinned to the top of the Roller site main blog." *2* Shareable posts. The ability for a user to post to more than one blog at a time. Rather than copying them, I think what we'd do is have the blog entry be authored for one blog, but then have the ability for the author (or another author on that blog) to share them with other blogs. I'm unsure whether the permissions should be: i) An author can share to any blog that they have write permissions to. ii) An author can share to any blog that is set up as able to share to in the blog's permissions (regardless of permissions). iii) Both of the above; ie) configure the blogs you can share to AND need perms. Sorry if these ideas have already come up, I'm not that up to date on all the proposals and various features in use at different installs. Hen
Re: Wiki access for new proposals
Thank you very much. -Elias Henri Yandell wrote: > Done. > > On 2/26/07, Elias Torres <[EMAIL PROTECTED]> wrote: >> Henry. ping. >> >> -Elias >> >> Anil Gangolli wrote: >> > >> > Henri set me up at some point. Let's bug him... >> > >> > --a. >> > >> > - Original Message - From: "Elias Torres" <[EMAIL PROTECTED]> >> > To: >> > Sent: Wednesday, February 21, 2007 5:19 PM >> > Subject: Wiki access for new proposals >> > >> > >> >> I can't seem to know or have the access to edit pages in our wiki. My >> >> username is eliast. >> >> >> >> I would like to propose a couple of features/fixes. >> >> >> >> - Design on the fixes we had agreed last year on TaskLease and how it >> >> can work better in a clustered environment. >> >> >> >> - Distributed search. Rewriting our search engine implementation to >> deal >> >> with multiple nodes in the cluster and also avoid having to >> recreate the >> >> indexes upon improper shutdown. >> >> >> >> - Reverse proxy support >> >> >> >> - Option to disable page output caching >> >> >> >> - Search feeds >> >> >> >> - Feed history >> >> >> >> - Authenticated comments >> >> >> >> That's all for now. >> >> >> >> -Elias >> >> >> > >> >
Re: Wiki access for new proposals
Done. On 2/26/07, Elias Torres <[EMAIL PROTECTED]> wrote: Henry. ping. -Elias Anil Gangolli wrote: > > Henri set me up at some point. Let's bug him... > > --a. > > - Original Message - From: "Elias Torres" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, February 21, 2007 5:19 PM > Subject: Wiki access for new proposals > > >> I can't seem to know or have the access to edit pages in our wiki. My >> username is eliast. >> >> I would like to propose a couple of features/fixes. >> >> - Design on the fixes we had agreed last year on TaskLease and how it >> can work better in a clustered environment. >> >> - Distributed search. Rewriting our search engine implementation to deal >> with multiple nodes in the cluster and also avoid having to recreate the >> indexes upon improper shutdown. >> >> - Reverse proxy support >> >> - Option to disable page output caching >> >> - Search feeds >> >> - Feed history >> >> - Authenticated comments >> >> That's all for now. >> >> -Elias >> >
Re: Wiki access for new proposals
Henry. ping. -Elias Anil Gangolli wrote: > > Henri set me up at some point. Let's bug him... > > --a. > > - Original Message - From: "Elias Torres" <[EMAIL PROTECTED]> > To: > Sent: Wednesday, February 21, 2007 5:19 PM > Subject: Wiki access for new proposals > > >> I can't seem to know or have the access to edit pages in our wiki. My >> username is eliast. >> >> I would like to propose a couple of features/fixes. >> >> - Design on the fixes we had agreed last year on TaskLease and how it >> can work better in a clustered environment. >> >> - Distributed search. Rewriting our search engine implementation to deal >> with multiple nodes in the cluster and also avoid having to recreate the >> indexes upon improper shutdown. >> >> - Reverse proxy support >> >> - Option to disable page output caching >> >> - Search feeds >> >> - Feed history >> >> - Authenticated comments >> >> That's all for now. >> >> -Elias >> >
Proposals
Hello, In addition to the work that Lotus is doing with Roller on it's Lotus Connections project, the IBM CIO Innovation Lab is currently working on rolling out a new version of it's intranet blogging environment based on the Lotus Connections blogging component. We are adding several features of our own that we're interested in contributing back to the Roller base. Not all of these have been fully implemented yet and we'd definitely need to execute a code grant before we can contribute the code but I wanted to at least start the discussion. 1. Rating system and featured posts - This adds a five-star rating for all entries. Only authenticated users can add and modify ratings for entries. The ratings are stored in a new DB table called roller_weblogentry_ratings. Only full-star ratings are allowed with averages rounded down to the nearest integer. The rating is then factored into a new "Featured Posts" feature that selects posts from a given timeframe using a non-deterministic algorithm that gives higher priority to posts that have the highest user ratings and comment counts. The algorithm was developed so that obviously popular entries are highlighted while giving less popular bloggers in the system a chance of being featured. 2. Extended blog statistics - primarily for our own internal tracking, we have developed a suite of extended statistical and utility functions. These include: * total number of active blogs * total number of entries * total number of comments * total number of users within specific email domains (since our email domains represent geographical dispersion, this helps us track our growth across various geographies) * total number of distinct tags * listing of similar tags (e.g. ibm, ibm, rolleratibm, etc) * related tags (tags that are used frequently with a specified tag) * tracking growth of users/blogs/tags over time * listing of related blogs (blogs that use the same tags as a specified blog) * listing of related entries (entries that use the same tags as a specified entry) * listing of the most popular entries * listing of frequent commenters to a specific blog * tracking the "decay" of blogs overtime. Decay is defined as the average rate of blog abandonment. There are other stats and I'm likely to add more. Each of the stats are available in as graphs in either JSON or CSV format. 3. Blog and User Search -- search for weblogs and users in the system rather than entries. The user search piece depends on a "profile provider" capable of calling out to an external "profile service". For our internal stuff, we're using the Lotus Connections profile service but I'm implementing this piece so that other provider implementations could be used (e.g. searching an LDAP directory). I do not plan, however, to implement any other providers -- at least not in the near term. 4. Apache Abdera-based Atom Publishing Protocol implementation. I've got a fully functional and spec-compliant implementation of the Atom Publishing Protocol based on Apache Abdera up and running. I know that Dave already has an implementation in the SVN. I'd like to contribute this but I'd understand if y'all didn't want it. - James
Re: Wiki access for new proposals
Henri set me up at some point. Let's bug him... --a. - Original Message - From: "Elias Torres" <[EMAIL PROTECTED]> To: Sent: Wednesday, February 21, 2007 5:19 PM Subject: Wiki access for new proposals I can't seem to know or have the access to edit pages in our wiki. My username is eliast. I would like to propose a couple of features/fixes. - Design on the fixes we had agreed last year on TaskLease and how it can work better in a clustered environment. - Distributed search. Rewriting our search engine implementation to deal with multiple nodes in the cluster and also avoid having to recreate the indexes upon improper shutdown. - Reverse proxy support - Option to disable page output caching - Search feeds - Feed history - Authenticated comments That's all for now. -Elias
Wiki access for new proposals
I can't seem to know or have the access to edit pages in our wiki. My username is eliast. I would like to propose a couple of features/fixes. - Design on the fixes we had agreed last year on TaskLease and how it can work better in a clustered environment. - Distributed search. Rewriting our search engine implementation to deal with multiple nodes in the cluster and also avoid having to recreate the indexes upon improper shutdown. - Reverse proxy support - Option to disable page output caching - Search feeds - Feed history - Authenticated comments That's all for now. -Elias
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
I haven't heard back from the JRoller guys, but I would have to assume that they'd agree with Allen on this. We need to allow old and new macros/models to exist in the same theme to ease the transtion for bloggers who want to move from 2.0 style to 3.0 style. That's how the code in the Roller 3.0 branch works now. Old and new can co-exist. - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
>> 4. I'd like to suggest that the new WeblogPageModel have a different >> name. $pageModel doesn't mean anything to ordinary users, so picking >> something shorter and more descriptive would be good. I think the names >> for $config, $site, and $planet are all good. All the other context >> objects sound fine to me as well. > > How about $page or $roller? Turns out we can't use $page because we're already using that. I don't like $roller all that much. So how about simply $model, after all, it's the only model most template authors will ever deal with. - Dave
Re: New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models)
Just to wrap this up: We're going with init(Map map) so that (someday) we can remove Servlet API stuff from our page models (or some subset of them) and support static rendering. - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
With the emergent of new technologies JSF, STRUTS ACTION2, SHALE and VELOCITY or even PHP as in NING.com example, how do we keep everyone happy with a view that is independent? The concept of shale seems to address this issue. If Roller can be written independent of view technology (since most are embracing the ease of use UI technology from JSF) and the advantages offered by POJO making note of JPA and EJB 3.0 we can all achieve harmony. Roller can come with a default setting as it is in present state but also easily adaptable to other states regardless of underlying data persistent mechanism and also its view presentation state. Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > On 6/15/06, Dave Johnson wrote: >> Thanks for the feedback. Lots of good suggestions there. >> >> On 6/14/06, Allen Gilliland wrote: >> > I think this looks good and will be a give improvement over what we >> > currently have. Here's a few notes/comments ... >> > >> > 6. You have a section called "Changes to existing POJOs" where you list >> > new methods to be added. This is the part I disagree with the most so >> > far. I don't think those methods should be added to our existing POJOs >> > because they are not related to the domain model in any way, they are >> > only related to the way we render our UI. I would much prefer to see >> > these methods be added to a class which extends the current pojos. >> This >> > also has the benefit that we don't need new methods for some things >> like >> > getTransformedText(), instead I think we should just override the >> > default pojos getText() method to return the transformed text. >> >> Yes. I like the idea of extending the POJOs. I'll update the proposal. > > On second thought, I'm not sure about this one. > > First, the new methods are related to our domain model. No matter what > your context is, if you are calling the Roller interfaces and dealing > with POJOs you're going to want to do things like getTransformedText() > to get the plugin processed version of the entry. Transforming text is > not part of the editor UI or the renderer UI, it's an operation that > the entry should provide. For example, if you're writing a command > line utility that calls the Roller interfaces to perform a system > backup or weblog export, you'd need that method. I would argue that a cmdline tool is a UI, but yes, I see your point. Some of those methods may be part of the domain model and in those cases it's obviously okay if the methods go directly into the pojos. I think we should have a little bit of discussion about which methods those are though, so that we don't end up mixing rendering and business logic. > > Second, how do we go from a list of WeblogEntryData objects returned > by the backend to a list of wrapped WeblogEntryDataEx objects? Do we > do a copyFrom operation for each object? Do we extend the wrapper > instead? Or do we just map the extended WeblogEntryDataEx object via > Hibernate and persist it instead? Those aren't really appealing > options. I am definitely not suggesting that Hibernate be involved in this. The extended version of the object should never even be conceived of outside of the UI layer. That being said, maybe extending pojos isn't the best way to have described this. I would say that using a wrapper is the better solution, or in this case we would extend our auto generated wrappers. I am not particularly crazy about extending auto generated classes, but that's part of the reason why I originally suggested that we maintain the wrappers manually. My opinion is that in the rendering system we should attempt to just used the wrapped versions of the pojos for everything. There is no reason why templates need access to non-relevant business methods during rendering. Hiding those methods and data seems like a good idea to me. > > I don't like mixing UI into the POJOs either and I don't want to > introduce any dependency on Servlet API or Struts or Velocity, but > there are cases where POJOs need to know URLs and cases POJOs should > be expected do rendering-related things (i.e. getTransformedText()). Agreed, but I still want to make sure we are making thoughtful decisions here. Mixing UI and business logic is definitely a bad thing, so we want to tread carefully here. I think one of the other technical limitations that prevented us from processing more urls in the pojos in the past is that we had this expectation that only the presentation layer can know what the app context was and it's root url, but if we overcome that problem then we can rethink that a little bit. I know that you created that absContextUrl param in the RollerConfig and are setting it dynamically now, but I think that may not be the best approach. I think it's better if we force users to set the site's absolute url as part of the install process, once that is done then constructing all the urls in the system is trivi
Re: New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models)
another thought below ... Allen Gilliland wrote: comments below ... Dave Johnson wrote: Comments inline... On 6/17/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> I am thinking that we could modify that init() method to this ... >> >> public void init(Map data) throws ModelInitializationException; > >> ... this way whatever piece of code is initializing that page model can >> pass in a set of data that may be useful to the page model. We also >> allow the page model to throw an exception during init if somehow the >> page model doesn't receive all the data it needs or something else bad >> happens during init. >> >> think that makes sense? > > I don't think we can anticipate all of the things that a page model > author will need to access within a model and using a request here > stikes a good balance. Authors have access to the request and at the > same time we can provide access to request related things like the > parsed WeblogPageRequest object via request attibutes. I agree, we can't anticipate everything that a page model would need, but to me that is more of a reason to give it mode data than less data. I definitely think that the original request will still go in the Map of data passed into each page model, but using the Map instead of just the request has a couple benefits in my mind ... The request attribute already give us a map: request attributes. 1. It's extensible. If at any time in the future we decide that each page model should have something else at init time then it's trivial to add it. Using just the request means we would have to refactor the interface and all implementors to fit the need. Could use request attributes, that's what they're for. 2. Custom implementations have more options. What if someone wants to create their own servlet to add some functionality that we don't provide and they create a custom page model for it? What if they want that page model to be initialized with more data. Using a Map makes that easy because the code that constructs the page model can pass in any data they want. 3. It's more efficient. In many cases a servlet or other code will already have done some parsing/validation on the request before the page model is constructed. Why force that work to be duplicated? By letting additional objects be passed into the init method we can reduce redundant work like parsing the request, looking up pojos like the Website object, etc. The model could just pull a parsed WeblogRequest object from the request attributes. I would have added "easier unit testing" as an advantage to using a Map, but the fact that all page models need the request negates that advantage. So I think I am still a fan of using a Map instead of just the servlet request for page model init. I don't think there is anything to lose by doing it. We could alternatively have the init method be init(request, Map data), so the page model is guaranteed to get the request and the Map is purely optional extra data. I really don't like the idea of sticking the request in a map. So if you insist on a map, I'd like to do as you suggest: init(request, Map) weird, i thought i had actually suggested that, but maybe i just thought about it and didn't say it. in any case, yes, i think this is a better approach than just using a map. i still prefer this approach over using request attributes mainly because the problem with request attributes is that they are then attached to the request for the rest of its processing, which may not be desired. the data we are planning to put in the Map is supposed to only be made available to the page model, so i think it's a bit cleaner to use our own Map rather than request attributes. One additional thing to consider is that on some level it may be undesirable to have the page model be based off of the request object. I'm not really sure if that's practical yet, but if you consider that we would like to be able to support static rendering of any page at some point then the request probably shouldn't be part of the page model. For static page rendering you would need to be able to construct page models without the use of a request, so maybe it's better if instead of using a request we break things down into our own set of objects which get passed into the page model init() method. This way we can ensure that page models are not tied to the request/response cycle. -- Allen -- Allen - Dave
Re: New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models)
comments below ... Dave Johnson wrote: Comments inline... On 6/17/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> I am thinking that we could modify that init() method to this ... >> >> public void init(Map data) throws ModelInitializationException; > >> ... this way whatever piece of code is initializing that page model can >> pass in a set of data that may be useful to the page model. We also >> allow the page model to throw an exception during init if somehow the >> page model doesn't receive all the data it needs or something else bad >> happens during init. >> >> think that makes sense? > > I don't think we can anticipate all of the things that a page model > author will need to access within a model and using a request here > stikes a good balance. Authors have access to the request and at the > same time we can provide access to request related things like the > parsed WeblogPageRequest object via request attibutes. I agree, we can't anticipate everything that a page model would need, but to me that is more of a reason to give it mode data than less data. I definitely think that the original request will still go in the Map of data passed into each page model, but using the Map instead of just the request has a couple benefits in my mind ... The request attribute already give us a map: request attributes. 1. It's extensible. If at any time in the future we decide that each page model should have something else at init time then it's trivial to add it. Using just the request means we would have to refactor the interface and all implementors to fit the need. Could use request attributes, that's what they're for. 2. Custom implementations have more options. What if someone wants to create their own servlet to add some functionality that we don't provide and they create a custom page model for it? What if they want that page model to be initialized with more data. Using a Map makes that easy because the code that constructs the page model can pass in any data they want. 3. It's more efficient. In many cases a servlet or other code will already have done some parsing/validation on the request before the page model is constructed. Why force that work to be duplicated? By letting additional objects be passed into the init method we can reduce redundant work like parsing the request, looking up pojos like the Website object, etc. The model could just pull a parsed WeblogRequest object from the request attributes. I would have added "easier unit testing" as an advantage to using a Map, but the fact that all page models need the request negates that advantage. So I think I am still a fan of using a Map instead of just the servlet request for page model init. I don't think there is anything to lose by doing it. We could alternatively have the init method be init(request, Map data), so the page model is guaranteed to get the request and the Map is purely optional extra data. I really don't like the idea of sticking the request in a map. So if you insist on a map, I'd like to do as you suggest: init(request, Map) weird, i thought i had actually suggested that, but maybe i just thought about it and didn't say it. in any case, yes, i think this is a better approach than just using a map. i still prefer this approach over using request attributes mainly because the problem with request attributes is that they are then attached to the request for the rest of its processing, which may not be desired. the data we are planning to put in the Map is supposed to only be made available to the page model, so i think it's a bit cleaner to use our own Map rather than request attributes. -- Allen - Dave
Re: New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models)
Comments inline... On 6/17/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> I am thinking that we could modify that init() method to this ... >> >> public void init(Map data) throws ModelInitializationException; > >> ... this way whatever piece of code is initializing that page model can >> pass in a set of data that may be useful to the page model. We also >> allow the page model to throw an exception during init if somehow the >> page model doesn't receive all the data it needs or something else bad >> happens during init. >> >> think that makes sense? > > I don't think we can anticipate all of the things that a page model > author will need to access within a model and using a request here > stikes a good balance. Authors have access to the request and at the > same time we can provide access to request related things like the > parsed WeblogPageRequest object via request attibutes. I agree, we can't anticipate everything that a page model would need, but to me that is more of a reason to give it mode data than less data. I definitely think that the original request will still go in the Map of data passed into each page model, but using the Map instead of just the request has a couple benefits in my mind ... The request attribute already give us a map: request attributes. 1. It's extensible. If at any time in the future we decide that each page model should have something else at init time then it's trivial to add it. Using just the request means we would have to refactor the interface and all implementors to fit the need. Could use request attributes, that's what they're for. 2. Custom implementations have more options. What if someone wants to create their own servlet to add some functionality that we don't provide and they create a custom page model for it? What if they want that page model to be initialized with more data. Using a Map makes that easy because the code that constructs the page model can pass in any data they want. 3. It's more efficient. In many cases a servlet or other code will already have done some parsing/validation on the request before the page model is constructed. Why force that work to be duplicated? By letting additional objects be passed into the init method we can reduce redundant work like parsing the request, looking up pojos like the Website object, etc. The model could just pull a parsed WeblogRequest object from the request attributes. I would have added "easier unit testing" as an advantage to using a Map, but the fact that all page models need the request negates that advantage. So I think I am still a fan of using a Map instead of just the servlet request for page model init. I don't think there is anything to lose by doing it. We could alternatively have the init method be init(request, Map data), so the page model is guaranteed to get the request and the Map is purely optional extra data. I really don't like the idea of sticking the request in a map. So if you insist on a map, I'd like to do as you suggest: init(request, Map) - Dave
Re: New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models)
Dave Johnson wrote: On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: I am thinking that we could modify that init() method to this ... public void init(Map data) throws ModelInitializationException; ... this way whatever piece of code is initializing that page model can pass in a set of data that may be useful to the page model. We also allow the page model to throw an exception during init if somehow the page model doesn't receive all the data it needs or something else bad happens during init. think that makes sense? I don't think we can anticipate all of the things that a page model author will need to access within a model and using a request here stikes a good balance. Authors have access to the request and at the same time we can provide access to request related things like the parsed WeblogPageRequest object via request attibutes. I agree, we can't anticipate everything that a page model would need, but to me that is more of a reason to give it mode data than less data. I definitely think that the original request will still go in the Map of data passed into each page model, but using the Map instead of just the request has a couple benefits in my mind ... 1. It's extensible. If at any time in the future we decide that each page model should have something else at init time then it's trivial to add it. Using just the request means we would have to refactor the interface and all implementors to fit the need. 2. Custom implementations have more options. What if someone wants to create their own servlet to add some functionality that we don't provide and they create a custom page model for it? What if they want that page model to be initialized with more data. Using a Map makes that easy because the code that constructs the page model can pass in any data they want. 3. It's more efficient. In many cases a servlet or other code will already have done some parsing/validation on the request before the page model is constructed. Why force that work to be duplicated? By letting additional objects be passed into the init method we can reduce redundant work like parsing the request, looking up pojos like the Website object, etc. So I think I am still a fan of using a Map instead of just the servlet request for page model init. I don't think there is anything to lose by doing it. We could alternatively have the init method be init(request, Map data), so the page model is guaranteed to get the request and the Map is purely optional extra data. -- Allen I do think the init method should throw an exception. The other smaller thing that I wanted to touch on is the idea that page models do not need to be so generic that they don't behave differently given different input. I think that some page models will certainly want to behave a little differently based on the input they are given during initialization. A good example of this would be the WeblogPageModel. I think it could be very useful if this model had a method like getEntries() which simply returned the list of entries represented by the request the model was constructed for. So if the request was for the weblog homepage then it returns the most recent XX entries as defined by the weblog settings. If the request is for a permalink then it returns only a single entry. If the request is constrained by date, category, etc, then it returns only the entries that are appropriate. Yes and that's essentially how the page model works now. It behaves differerently based on what is in the request, so it does different things if a specific day or month is specified. The benefit of an approach like this is that it takes the logic of what entries to query for out of the macros and puts it into the model. This is good because it keeps logic out of the "View" which is supposed to only deal with display stuff. Another example might be methods like getNextPageLink() and getPrevPageLink() which may return links to the next/prev month in one condition, but return links to next/prev entry in another situation. The logic would be built into the method so that the view doesn't need to worry about whether it's looking for the next entry, next month, next entry in category, etc. All it needs is to ask for the next/prev links and it gets back the right thing. Yep. That's how they worked in 2.0 and they should continue to work. - Dave
Re: New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models)
comment inline - Original Message - From: "Dave Johnson" <[EMAIL PROTECTED]> To: Sent: Friday, June 16, 2006 2:28 PM Subject: Re: New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models) On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: I am thinking that we could modify that init() method to this ... public void init(Map data) throws ModelInitializationException; ... this way whatever piece of code is initializing that page model can pass in a set of data that may be useful to the page model. We also allow the page model to throw an exception during init if somehow the page model doesn't receive all the data it needs or something else bad happens during init. think that makes sense? I don't think we can anticipate all of the things that a page model author will need to access within a model and using a request here stikes a good balance. Authors have access to the request and at the same time we can provide access to request related things like the parsed WeblogPageRequest object via request attibutes. I do think the init method should throw an exception. This suggests it would be a checked exception. I don't see any reason not to make ModelInitializationException a subclass of RuntimeException here.
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
Dave Johnson wrote: On 6/15/06, Dave Johnson <[EMAIL PROTECTED]> wrote: Thanks for the feedback. Lots of good suggestions there. On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > I think this looks good and will be a give improvement over what we > currently have. Here's a few notes/comments ... > > 6. You have a section called "Changes to existing POJOs" where you list > new methods to be added. This is the part I disagree with the most so > far. I don't think those methods should be added to our existing POJOs > because they are not related to the domain model in any way, they are > only related to the way we render our UI. I would much prefer to see > these methods be added to a class which extends the current pojos. This > also has the benefit that we don't need new methods for some things like > getTransformedText(), instead I think we should just override the > default pojos getText() method to return the transformed text. Yes. I like the idea of extending the POJOs. I'll update the proposal. On second thought, I'm not sure about this one. First, the new methods are related to our domain model. No matter what your context is, if you are calling the Roller interfaces and dealing with POJOs you're going to want to do things like getTransformedText() to get the plugin processed version of the entry. Transforming text is not part of the editor UI or the renderer UI, it's an operation that the entry should provide. For example, if you're writing a command line utility that calls the Roller interfaces to perform a system backup or weblog export, you'd need that method. I would argue that a cmdline tool is a UI, but yes, I see your point. Some of those methods may be part of the domain model and in those cases it's obviously okay if the methods go directly into the pojos. I think we should have a little bit of discussion about which methods those are though, so that we don't end up mixing rendering and business logic. Second, how do we go from a list of WeblogEntryData objects returned by the backend to a list of wrapped WeblogEntryDataEx objects? Do we do a copyFrom operation for each object? Do we extend the wrapper instead? Or do we just map the extended WeblogEntryDataEx object via Hibernate and persist it instead? Those aren't really appealing options. I am definitely not suggesting that Hibernate be involved in this. The extended version of the object should never even be conceived of outside of the UI layer. That being said, maybe extending pojos isn't the best way to have described this. I would say that using a wrapper is the better solution, or in this case we would extend our auto generated wrappers. I am not particularly crazy about extending auto generated classes, but that's part of the reason why I originally suggested that we maintain the wrappers manually. My opinion is that in the rendering system we should attempt to just used the wrapped versions of the pojos for everything. There is no reason why templates need access to non-relevant business methods during rendering. Hiding those methods and data seems like a good idea to me. I don't like mixing UI into the POJOs either and I don't want to introduce any dependency on Servlet API or Struts or Velocity, but there are cases where POJOs need to know URLs and cases POJOs should be expected do rendering-related things (i.e. getTransformedText()). Agreed, but I still want to make sure we are making thoughtful decisions here. Mixing UI and business logic is definitely a bad thing, so we want to tread carefully here. I think one of the other technical limitations that prevented us from processing more urls in the pojos in the past is that we had this expectation that only the presentation layer can know what the app context was and it's root url, but if we overcome that problem then we can rethink that a little bit. I know that you created that absContextUrl param in the RollerConfig and are setting it dynamically now, but I think that may not be the best approach. I think it's better if we force users to set the site's absolute url as part of the install process, once that is done then constructing all the urls in the system is trivial. I believe most other blog software does this and I don't think it's a big deal. This is the approach I would vote for. -- Allen - Dave
Re: New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models)
On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: I am thinking that we could modify that init() method to this ... public void init(Map data) throws ModelInitializationException; ... this way whatever piece of code is initializing that page model can pass in a set of data that may be useful to the page model. We also allow the page model to throw an exception during init if somehow the page model doesn't receive all the data it needs or something else bad happens during init. think that makes sense? I don't think we can anticipate all of the things that a page model author will need to access within a model and using a request here stikes a good balance. Authors have access to the request and at the same time we can provide access to request related things like the parsed WeblogPageRequest object via request attibutes. I do think the init method should throw an exception. The other smaller thing that I wanted to touch on is the idea that page models do not need to be so generic that they don't behave differently given different input. I think that some page models will certainly want to behave a little differently based on the input they are given during initialization. A good example of this would be the WeblogPageModel. I think it could be very useful if this model had a method like getEntries() which simply returned the list of entries represented by the request the model was constructed for. So if the request was for the weblog homepage then it returns the most recent XX entries as defined by the weblog settings. If the request is for a permalink then it returns only a single entry. If the request is constrained by date, category, etc, then it returns only the entries that are appropriate. Yes and that's essentially how the page model works now. It behaves differerently based on what is in the request, so it does different things if a specific day or month is specified. The benefit of an approach like this is that it takes the logic of what entries to query for out of the macros and puts it into the model. This is good because it keeps logic out of the "View" which is supposed to only deal with display stuff. Another example might be methods like getNextPageLink() and getPrevPageLink() which may return links to the next/prev month in one condition, but return links to next/prev entry in another situation. The logic would be built into the method so that the view doesn't need to worry about whether it's looking for the next entry, next month, next entry in category, etc. All it needs is to ask for the next/prev links and it gets back the right thing. Yep. That's how they worked in 2.0 and they should continue to work. - Dave
New page models design (was Re: Atlas proposals: Frontpage weblog and new Page Macro/Models)
Dave, I wanted to go back to the beginning of this discussion and sidetrack on a discussion about how the PageModel interface is defined and how the page models are instantiated and used. Right now the PageModel interface has this method for init ... public void init(HttpServletRequest request); ... and I'm wondering if it would be better to make that init method even more generic. I think that each page model implementation will probably want to get a different set of initial data to make use of in the model. For example, I can imagine that the WeblogPageModel may want to use a parsed WeblogPageRequest, or a WebsiteData and WeblogEntryData objects. So, I think there is definitely some potential uses for initializing a page model with more than just the request object. I am thinking that we could modify that init() method to this ... public void init(Map data) throws ModelInitializationException; ... this way whatever piece of code is initializing that page model can pass in a set of data that may be useful to the page model. We also allow the page model to throw an exception during init if somehow the page model doesn't receive all the data it needs or something else bad happens during init. think that makes sense? The other smaller thing that I wanted to touch on is the idea that page models do not need to be so generic that they don't behave differently given different input. I think that some page models will certainly want to behave a little differently based on the input they are given during initialization. A good example of this would be the WeblogPageModel. I think it could be very useful if this model had a method like getEntries() which simply returned the list of entries represented by the request the model was constructed for. So if the request was for the weblog homepage then it returns the most recent XX entries as defined by the weblog settings. If the request is for a permalink then it returns only a single entry. If the request is constrained by date, category, etc, then it returns only the entries that are appropriate. The benefit of an approach like this is that it takes the logic of what entries to query for out of the macros and puts it into the model. This is good because it keeps logic out of the "View" which is supposed to only deal with display stuff. Another example might be methods like getNextPageLink() and getPrevPageLink() which may return links to the next/prev month in one condition, but return links to next/prev entry in another situation. The logic would be built into the method so that the view doesn't need to worry about whether it's looking for the next entry, next month, next entry in category, etc. All it needs is to ask for the next/prev links and it gets back the right thing. Anyways, you may already have been planning on doing that, but I wanted to throw it out there anyways. -- Allen Dave Johnson wrote: I've already started implementation of the new Atlas frontpage proposal: http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_Atlas And today I posted the first draft of a new Atlas Page Macro/Models proposal: http://rollerweblogger.org/wiki/Wiki.jsp?page=ProposalAtlasMacroModels The new Atlas macro/models proposal is pretty significant. I'm proposing that we replace the old page models and macros that are used in all existing Roller themes with an entirely new set of models and macros. It's important that we get this right -- we don't want to have to do this again. The old system will still be available, but it will be possible to either 1) leave it in place, 2) leave it in place but not allow new blogs to use it or 3) to turn if off entirely. Please review and offer feedback. - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
Dave Johnson wrote: On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: comments below ... Dave Johnson wrote: > On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> >> >> Dave Johnson wrote: >> > If we do things right we can completely avoid the problem you mention. >> > Here's a slight adjustment to the options I presented before. With >> the part >> > I added about the theme chooser, I don't think there is any room for a >> > theme/model mix up here. >> > >> > 1 - Turn on Atlas, completely turn off old model >> > site.macromodel="roller_3.0_only" >> > Velocity context loaded with only NEW model stuff >> > Create weblog page shows only NEW themes >> > *** Theme chooser shows only NEW themes based on website.macroVersion >> > This is the default for new installations >> > >> > 2 - Turn on Atlas, but continue to support old model >> > site.macromodel=roller_3.0 >> > Create weblog page shows NEW themes only, defaults to new model >> > Velocity context loaded with either OLD or NEW model stuff, >> > website.macromodel >> > *** Theme chooser shows OLD or NEW themes based on website.macromodel >> > This is the default for upgrades >> >> How do you know if a theme is old or new? I can imagine a way to hack >> some knowledge about what is new/old for themes Roller ships with, but >> not custom themes. If I have a custom theme called "xxx" in my >> installation, how do you know if it's old or new? > > > Hmmm > > All existing weblogs are marked as weblog.macromodel=roller_2.0 > And they can only pick old themes. > > New weblogs get weblog.macromodel=roller_3.0 > And they can only pick new themes. right, that's the easy part. > > So there's no quesiton there, we know what type of themes blogs are using. > > So how do we know which model a given theme uses? > > New themes files are placed in a new directory or we put a marker file > into new theme directories. Perhaps we have a convention that new > themes must contain a preview image file named preview.jpg. Or perhaps > we introduce a theme.xml file that goes into each theme direcory. Or > maybe just a theme.properties file. > > > ThemeName > ThemeName > Theme description, blah > text/html > page > That works, but it's another layer of complexity being added to the 3.0 release. I was planning to do something like this after 3.0 as part of an effort to refine the theme system and make it easier to plug in new themes. If we do this now I'd like to keep it as simple as possible rather than try and come up with a full new metadata format for describing themes, I think that's starting to get a little out of scope for this release. Something simple that just marks which themes are 3.0 should be enough. > > How do you allow users to convert from 2.0 to 3.0? With the > arrangement I've outlined above, they must make a clean break. The > migrate to 3.0 UI must warn them, you will lose all customizations and > you must start fresh with a new theme. Sounds harsh, but If we allow > them to have access to both models, then I bet we'll see lots of > themes stuck half-way between 2.0 and 3.0. Right, this is the most difficult part. The other difficult part is how do you deal with users who have CUSTOM themes? Even if we start all existing weblogs with macromodel=2.0 how do we get CUSTOM theme users to upgrade without having to choose a new theme? What if the user just wants to use some of the new macros but not have to redo their whole theme? I also think that even if we ensure that technically users can't mix the 2 models, they are going to try anyways and it's going to be confusing for them. There's also potential issues where if users have custom non-theme templates in their weblog then those will just suddenly stop working properly if they upgrade to a 3.0 theme. I suppose we can just say "too bad", but that's rarely an option that users like to hear. My feeling is that sites like jRoller, with 10k blogs?, would have a pretty strong opinion about this. I think it would be very helpful if more people could be involved in this decision. Yes. I totally agree with that. I could go either way at this point. On one hand, I really like the clean break and avoiding the confusion of mixed themes. But on the other hand, I don't want to make the transition from custom 2.0 theme to custom 3.0 theme into a nightmare. Just so it's obvious, this is my feelings exactly. I would *love* to have a way to totally abandon the old macros and models and get all existing users transitioned to the new stuff, but I don't see any reasonable way to make that happen. If we can't figure out a good way to do that then I think the next best option is to make the 2 systems exist side by side and do everything in our power to get people to only use the new macros and models. So JRoller guys and others, speak up. please! -- Allen - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
On 6/16/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: comments below ... Dave Johnson wrote: > On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> >> >> Dave Johnson wrote: >> > If we do things right we can completely avoid the problem you mention. >> > Here's a slight adjustment to the options I presented before. With >> the part >> > I added about the theme chooser, I don't think there is any room for a >> > theme/model mix up here. >> > >> > 1 - Turn on Atlas, completely turn off old model >> > site.macromodel="roller_3.0_only" >> > Velocity context loaded with only NEW model stuff >> > Create weblog page shows only NEW themes >> > *** Theme chooser shows only NEW themes based on website.macroVersion >> > This is the default for new installations >> > >> > 2 - Turn on Atlas, but continue to support old model >> > site.macromodel=roller_3.0 >> > Create weblog page shows NEW themes only, defaults to new model >> > Velocity context loaded with either OLD or NEW model stuff, >> > website.macromodel >> > *** Theme chooser shows OLD or NEW themes based on website.macromodel >> > This is the default for upgrades >> >> How do you know if a theme is old or new? I can imagine a way to hack >> some knowledge about what is new/old for themes Roller ships with, but >> not custom themes. If I have a custom theme called "xxx" in my >> installation, how do you know if it's old or new? > > > Hmmm > > All existing weblogs are marked as weblog.macromodel=roller_2.0 > And they can only pick old themes. > > New weblogs get weblog.macromodel=roller_3.0 > And they can only pick new themes. right, that's the easy part. > > So there's no quesiton there, we know what type of themes blogs are using. > > So how do we know which model a given theme uses? > > New themes files are placed in a new directory or we put a marker file > into new theme directories. Perhaps we have a convention that new > themes must contain a preview image file named preview.jpg. Or perhaps > we introduce a theme.xml file that goes into each theme direcory. Or > maybe just a theme.properties file. > > > ThemeName > ThemeName > Theme description, blah > text/html > page > That works, but it's another layer of complexity being added to the 3.0 release. I was planning to do something like this after 3.0 as part of an effort to refine the theme system and make it easier to plug in new themes. If we do this now I'd like to keep it as simple as possible rather than try and come up with a full new metadata format for describing themes, I think that's starting to get a little out of scope for this release. Something simple that just marks which themes are 3.0 should be enough. > > How do you allow users to convert from 2.0 to 3.0? With the > arrangement I've outlined above, they must make a clean break. The > migrate to 3.0 UI must warn them, you will lose all customizations and > you must start fresh with a new theme. Sounds harsh, but If we allow > them to have access to both models, then I bet we'll see lots of > themes stuck half-way between 2.0 and 3.0. Right, this is the most difficult part. The other difficult part is how do you deal with users who have CUSTOM themes? Even if we start all existing weblogs with macromodel=2.0 how do we get CUSTOM theme users to upgrade without having to choose a new theme? What if the user just wants to use some of the new macros but not have to redo their whole theme? I also think that even if we ensure that technically users can't mix the 2 models, they are going to try anyways and it's going to be confusing for them. There's also potential issues where if users have custom non-theme templates in their weblog then those will just suddenly stop working properly if they upgrade to a 3.0 theme. I suppose we can just say "too bad", but that's rarely an option that users like to hear. My feeling is that sites like jRoller, with 10k blogs?, would have a pretty strong opinion about this. I think it would be very helpful if more people could be involved in this decision. Yes. I totally agree with that. I could go either way at this point. On one hand, I really like the clean break and avoiding the confusion of mixed themes. But on the other hand, I don't want to make the transition from custom 2.0 theme to custom 3.0 theme into a nightmare. So JRoller guys and others, speak up. - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
comments below ... Dave Johnson wrote: On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > If we do things right we can completely avoid the problem you mention. > Here's a slight adjustment to the options I presented before. With the part > I added about the theme chooser, I don't think there is any room for a > theme/model mix up here. > > 1 - Turn on Atlas, completely turn off old model > site.macromodel="roller_3.0_only" > Velocity context loaded with only NEW model stuff > Create weblog page shows only NEW themes > *** Theme chooser shows only NEW themes based on website.macroVersion > This is the default for new installations > > 2 - Turn on Atlas, but continue to support old model > site.macromodel=roller_3.0 > Create weblog page shows NEW themes only, defaults to new model > Velocity context loaded with either OLD or NEW model stuff, > website.macromodel > *** Theme chooser shows OLD or NEW themes based on website.macromodel > This is the default for upgrades How do you know if a theme is old or new? I can imagine a way to hack some knowledge about what is new/old for themes Roller ships with, but not custom themes. If I have a custom theme called "xxx" in my installation, how do you know if it's old or new? Hmmm All existing weblogs are marked as weblog.macromodel=roller_2.0 And they can only pick old themes. New weblogs get weblog.macromodel=roller_3.0 And they can only pick new themes. right, that's the easy part. So there's no quesiton there, we know what type of themes blogs are using. So how do we know which model a given theme uses? New themes files are placed in a new directory or we put a marker file into new theme directories. Perhaps we have a convention that new themes must contain a preview image file named preview.jpg. Or perhaps we introduce a theme.xml file that goes into each theme direcory. Or maybe just a theme.properties file. ThemeName ThemeName Theme description, blah text/html page That works, but it's another layer of complexity being added to the 3.0 release. I was planning to do something like this after 3.0 as part of an effort to refine the theme system and make it easier to plug in new themes. If we do this now I'd like to keep it as simple as possible rather than try and come up with a full new metadata format for describing themes, I think that's starting to get a little out of scope for this release. Something simple that just marks which themes are 3.0 should be enough. How do you allow users to convert from 2.0 to 3.0? With the arrangement I've outlined above, they must make a clean break. The migrate to 3.0 UI must warn them, you will lose all customizations and you must start fresh with a new theme. Sounds harsh, but If we allow them to have access to both models, then I bet we'll see lots of themes stuck half-way between 2.0 and 3.0. Right, this is the most difficult part. The other difficult part is how do you deal with users who have CUSTOM themes? Even if we start all existing weblogs with macromodel=2.0 how do we get CUSTOM theme users to upgrade without having to choose a new theme? What if the user just wants to use some of the new macros but not have to redo their whole theme? I also think that even if we ensure that technically users can't mix the 2 models, they are going to try anyways and it's going to be confusing for them. There's also potential issues where if users have custom non-theme templates in their weblog then those will just suddenly stop working properly if they upgrade to a 3.0 theme. I suppose we can just say "too bad", but that's rarely an option that users like to hear. My feeling is that sites like jRoller, with 10k blogs?, would have a pretty strong opinion about this. I think it would be very helpful if more people could be involved in this decision. -- Allen - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > If we do things right we can completely avoid the problem you mention. > Here's a slight adjustment to the options I presented before. With the part > I added about the theme chooser, I don't think there is any room for a > theme/model mix up here. > > 1 - Turn on Atlas, completely turn off old model > site.macromodel="roller_3.0_only" > Velocity context loaded with only NEW model stuff > Create weblog page shows only NEW themes > *** Theme chooser shows only NEW themes based on website.macroVersion > This is the default for new installations > > 2 - Turn on Atlas, but continue to support old model > site.macromodel=roller_3.0 > Create weblog page shows NEW themes only, defaults to new model > Velocity context loaded with either OLD or NEW model stuff, > website.macromodel > *** Theme chooser shows OLD or NEW themes based on website.macromodel > This is the default for upgrades How do you know if a theme is old or new? I can imagine a way to hack some knowledge about what is new/old for themes Roller ships with, but not custom themes. If I have a custom theme called "xxx" in my installation, how do you know if it's old or new? Hmmm All existing weblogs are marked as weblog.macromodel=roller_2.0 And they can only pick old themes. New weblogs get weblog.macromodel=roller_3.0 And they can only pick new themes. So there's no quesiton there, we know what type of themes blogs are using. So how do we know which model a given theme uses? New themes files are placed in a new directory or we put a marker file into new theme directories. Perhaps we have a convention that new themes must contain a preview image file named preview.jpg. Or perhaps we introduce a theme.xml file that goes into each theme direcory. Or maybe just a theme.properties file. ThemeName ThemeName Theme description, blah text/html page How do you allow users to convert from 2.0 to 3.0? With the arrangement I've outlined above, they must make a clean break. The migrate to 3.0 UI must warn them, you will lose all customizations and you must start fresh with a new theme. Sounds harsh, but If we allow them to have access to both models, then I bet we'll see lots of themes stuck half-way between 2.0 and 3.0. - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
Dave Johnson wrote: On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: More comments below ... Dave Johnson wrote: > Comments below... > > On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> Dave Johnson wrote: >> > Thanks for the feedback. Lots of good suggestions there. >> > On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > >> My biggest concern with this is doing it on a weblog by weblog basis, if >> we make this decision on a site-wide level then i think we will be in >> better shape. >> >> > 2 - Turn on Atlas, but continue to support old model >> > site.macromodel=roller_3.0 >> > Velocity context loaded with either OLD or NEW model stuff, >> depending on >> > blog >> > Create weblog page shows NEW themes only >> > This is the default for upgrades >> >> Again, doing this on a blog by blog basis has me *really* scared. I am >> okay with this option as a site-wide option, but I see a lot of >> potential problems doing it blog by blog. > > I don't understand your concern here. What problems do you think we'll hit? Well, take BSC for example. We've been using Roller since pre-1.0 days and we have a lot of old blogs and a big pile of users. When we upgrade to 3.0 we are going to have to maintain some backwards compatability for old themes, so we are going to have to keep them around using the old templates. What happens if a new user signs up, creates a blog with macromodel=3.0, and then tries to use one of the old themes? I don't see any (or reason?) for Roller to try and decide what themes a user has access to based on this setting, so it's entirely possible that a weblog with macromodel=3.0 will attempt to use some pre-3.0 template code. If we do things right we can completely avoid the problem you mention. Here's a slight adjustment to the options I presented before. With the part I added about the theme chooser, I don't think there is any room for a theme/model mix up here. 1 - Turn on Atlas, completely turn off old model site.macromodel="roller_3.0_only" Velocity context loaded with only NEW model stuff Create weblog page shows only NEW themes *** Theme chooser shows only NEW themes based on website.macroVersion This is the default for new installations 2 - Turn on Atlas, but continue to support old model site.macromodel=roller_3.0 Create weblog page shows NEW themes only, defaults to new model Velocity context loaded with either OLD or NEW model stuff, website.macromodel *** Theme chooser shows OLD or NEW themes based on website.macromodel This is the default for upgrades How do you know if a theme is old or new? I can imagine a way to hack some knowledge about what is new/old for themes Roller ships with, but not custom themes. If I have a custom theme called "xxx" in my installation, how do you know if it's old or new? -- Allen >> > One Roller site can support both classic and Atlas themes, but I >> > really want to avoid having themes that use a mix of classic and Atlas >> > macros. A weblog MUST pick which macro/model it will use. I was going >> > to use website.pageModels as a flag to indicate which macro/model, but >> > perhaps that is too confusing. Instead, we could force weblogs to >> > declare which version of macros should be used. >> > >> > website.macrosVersion=2.0 >> >> To be honest, I don't think this is realistic. I agree that this is the >> ideal way it would work, but I don't see it happening. We don't have >> any real way of ensuring that upgraded installations don't do something >> to make old template stuff available to weblogs that are set to use the >> 3.0 macros only. > > I'm more concerned about this one. I'd hate to see weblogs with a mix > of both schemes. I hate that thought as well, but I'm not sure we can prevent it. Maybe it's possible, i'd need to think about it more, but right now it seems problematic to me. Yes. Do think about it some more. Anybody else want to weigh in? - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: More comments below ... Dave Johnson wrote: > Comments below... > > On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: >> Dave Johnson wrote: >> > Thanks for the feedback. Lots of good suggestions there. >> > On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > >> My biggest concern with this is doing it on a weblog by weblog basis, if >> we make this decision on a site-wide level then i think we will be in >> better shape. >> >> > 2 - Turn on Atlas, but continue to support old model >> > site.macromodel=roller_3.0 >> > Velocity context loaded with either OLD or NEW model stuff, >> depending on >> > blog >> > Create weblog page shows NEW themes only >> > This is the default for upgrades >> >> Again, doing this on a blog by blog basis has me *really* scared. I am >> okay with this option as a site-wide option, but I see a lot of >> potential problems doing it blog by blog. > > I don't understand your concern here. What problems do you think we'll hit? Well, take BSC for example. We've been using Roller since pre-1.0 days and we have a lot of old blogs and a big pile of users. When we upgrade to 3.0 we are going to have to maintain some backwards compatability for old themes, so we are going to have to keep them around using the old templates. What happens if a new user signs up, creates a blog with macromodel=3.0, and then tries to use one of the old themes? I don't see any (or reason?) for Roller to try and decide what themes a user has access to based on this setting, so it's entirely possible that a weblog with macromodel=3.0 will attempt to use some pre-3.0 template code. If we do things right we can completely avoid the problem you mention. Here's a slight adjustment to the options I presented before. With the part I added about the theme chooser, I don't think there is any room for a theme/model mix up here. 1 - Turn on Atlas, completely turn off old model site.macromodel="roller_3.0_only" Velocity context loaded with only NEW model stuff Create weblog page shows only NEW themes *** Theme chooser shows only NEW themes based on website.macroVersion This is the default for new installations 2 - Turn on Atlas, but continue to support old model site.macromodel=roller_3.0 Create weblog page shows NEW themes only, defaults to new model Velocity context loaded with either OLD or NEW model stuff, website.macromodel *** Theme chooser shows OLD or NEW themes based on website.macromodel This is the default for upgrades >> > One Roller site can support both classic and Atlas themes, but I >> > really want to avoid having themes that use a mix of classic and Atlas >> > macros. A weblog MUST pick which macro/model it will use. I was going >> > to use website.pageModels as a flag to indicate which macro/model, but >> > perhaps that is too confusing. Instead, we could force weblogs to >> > declare which version of macros should be used. >> > >> > website.macrosVersion=2.0 >> >> To be honest, I don't think this is realistic. I agree that this is the >> ideal way it would work, but I don't see it happening. We don't have >> any real way of ensuring that upgraded installations don't do something >> to make old template stuff available to weblogs that are set to use the >> 3.0 macros only. > > I'm more concerned about this one. I'd hate to see weblogs with a mix > of both schemes. I hate that thought as well, but I'm not sure we can prevent it. Maybe it's possible, i'd need to think about it more, but right now it seems problematic to me. Yes. Do think about it some more. Anybody else want to weigh in? - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
More comments below ... Dave Johnson wrote: Comments below... On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > Thanks for the feedback. Lots of good suggestions there. > On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: My biggest concern with this is doing it on a weblog by weblog basis, if we make this decision on a site-wide level then i think we will be in better shape. > 2 - Turn on Atlas, but continue to support old model > site.macromodel=roller_3.0 > Velocity context loaded with either OLD or NEW model stuff, depending on > blog > Create weblog page shows NEW themes only > This is the default for upgrades Again, doing this on a blog by blog basis has me *really* scared. I am okay with this option as a site-wide option, but I see a lot of potential problems doing it blog by blog. I don't understand your concern here. What problems do you think we'll hit? Well, take BSC for example. We've been using Roller since pre-1.0 days and we have a lot of old blogs and a big pile of users. When we upgrade to 3.0 we are going to have to maintain some backwards compatability for old themes, so we are going to have to keep them around using the old templates. What happens if a new user signs up, creates a blog with macromodel=3.0, and then tries to use one of the old themes? I don't see any (or reason?) for Roller to try and decide what themes a user has access to based on this setting, so it's entirely possible that a weblog with macromodel=3.0 will attempt to use some pre-3.0 template code. > One Roller site can support both classic and Atlas themes, but I > really want to avoid having themes that use a mix of classic and Atlas > macros. A weblog MUST pick which macro/model it will use. I was going > to use website.pageModels as a flag to indicate which macro/model, but > perhaps that is too confusing. Instead, we could force weblogs to > declare which version of macros should be used. > > website.macrosVersion=2.0 To be honest, I don't think this is realistic. I agree that this is the ideal way it would work, but I don't see it happening. We don't have any real way of ensuring that upgraded installations don't do something to make old template stuff available to weblogs that are set to use the 3.0 macros only. I'm more concerned about this one. I'd hate to see weblogs with a mix of both schemes. I hate that thought as well, but I'm not sure we can prevent it. Maybe it's possible, i'd need to think about it more, but right now it seems problematic to me. >> 3. I think we need to have a little more discussion about the feed urls. >> I didn't realize that the comment feeds needed to be available in both >> rss and atom, because that causes a problem with the current url >> proposal. If we are planning to offer each possible feed in multiple >> flavors (rss, atom, etc) then we need to plan for that a bit better. > > Best practice is to offer one feed format, so that's what I'd like > Roller to do by default. Each weblog has two feeds: one for entries > and one for comments. The feed format used by these feeds is > determined by the weblog's website.feedType field, which may be either > "atom_1.0" or "rss_2.0". Hmm, this one has me a bit worried as well. Why is it a best practice to only offer one type of feed format? Seems to me that only alienates some users who can only support either rss or atom, but not both. I prefer that we be able to support both feed types at the same time. Anyone else know much about this? Should we offer both atom and rss feeds for everything, or try and pick one or the other? All feed readers support both Atom and RSS these days, so we're not going to alientate anybody. I suppose we could offer, but not advertise (via autodisco or otherwise) alternate formats using a flavor= parameter, but I definitely like the idea of pick one. And the Microsoft recommendations http://blogs.msdn.com/rssteam/archive/2005/08/03/446904.aspx Here's feed reader developere Nick Bradbury on the topic: http://nick.typepad.com/blog/2006/05/pick_a_format_a.html Google's Crazy Bob: http://crazybob.org/2006/04/why-do-sites-provide-both-rss-and-atom.html And a +1 from Sam Ruby http://www.intertwingly.net/blog/2006/05/25/Pick-ONE Fair enough. If others on the list agree then let's just force people to pick one. And yes, I was thinking more about auto discovery links than hard links on the page. With autodiscovery i don't see any reason not to include both feed types. -- Allen - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
Comments below... On 6/15/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: Dave Johnson wrote: > Thanks for the feedback. Lots of good suggestions there. > On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: My biggest concern with this is doing it on a weblog by weblog basis, if we make this decision on a site-wide level then i think we will be in better shape. > 2 - Turn on Atlas, but continue to support old model > site.macromodel=roller_3.0 > Velocity context loaded with either OLD or NEW model stuff, depending on > blog > Create weblog page shows NEW themes only > This is the default for upgrades Again, doing this on a blog by blog basis has me *really* scared. I am okay with this option as a site-wide option, but I see a lot of potential problems doing it blog by blog. I don't understand your concern here. What problems do you think we'll hit? > One Roller site can support both classic and Atlas themes, but I > really want to avoid having themes that use a mix of classic and Atlas > macros. A weblog MUST pick which macro/model it will use. I was going > to use website.pageModels as a flag to indicate which macro/model, but > perhaps that is too confusing. Instead, we could force weblogs to > declare which version of macros should be used. > > website.macrosVersion=2.0 To be honest, I don't think this is realistic. I agree that this is the ideal way it would work, but I don't see it happening. We don't have any real way of ensuring that upgraded installations don't do something to make old template stuff available to weblogs that are set to use the 3.0 macros only. I'm more concerned about this one. I'd hate to see weblogs with a mix of both schemes. >> 3. I think we need to have a little more discussion about the feed urls. >> I didn't realize that the comment feeds needed to be available in both >> rss and atom, because that causes a problem with the current url >> proposal. If we are planning to offer each possible feed in multiple >> flavors (rss, atom, etc) then we need to plan for that a bit better. > > Best practice is to offer one feed format, so that's what I'd like > Roller to do by default. Each weblog has two feeds: one for entries > and one for comments. The feed format used by these feeds is > determined by the weblog's website.feedType field, which may be either > "atom_1.0" or "rss_2.0". Hmm, this one has me a bit worried as well. Why is it a best practice to only offer one type of feed format? Seems to me that only alienates some users who can only support either rss or atom, but not both. I prefer that we be able to support both feed types at the same time. Anyone else know much about this? Should we offer both atom and rss feeds for everything, or try and pick one or the other? All feed readers support both Atom and RSS these days, so we're not going to alientate anybody. I suppose we could offer, but not advertise (via autodisco or otherwise) alternate formats using a flavor= parameter, but I definitely like the idea of pick one. And the Microsoft recommendations http://blogs.msdn.com/rssteam/archive/2005/08/03/446904.aspx Here's feed reader developere Nick Bradbury on the topic: http://nick.typepad.com/blog/2006/05/pick_a_format_a.html Google's Crazy Bob: http://crazybob.org/2006/04/why-do-sites-provide-both-rss-and-atom.html And a +1 from Sam Ruby http://www.intertwingly.net/blog/2006/05/25/Pick-ONE - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
Comments inline ... Dave Johnson wrote: Thanks for the feedback. Lots of good suggestions there. Comments inliine... On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: I think this looks good and will be a give improvement over what we currently have. Here's a few notes/comments ... 1. I don't understand what "Page models return collections of POJOs" means. I don't consider that a requirement of a PageModel. I think a PageModel can return any type of object it wants. Can you explain what you meant by that? Aside from that I agree with your definition and what models we will have. You're right. Page models don't only return POJOs. I'll strike that. 2. I am a little uncertain about the whole website.pageModels and configuring different blogs with different models. I think this idea sounds good, but I am worried it's going to invite lots of problems, particularly for sites that are upgrading. Older sites are going to have a mix of old stuff on their site which needs to be supported, so I'm not sure we can really offer a weblog by weblog config option to alter the model. For example, what if someone upgrading from 2.x wants to keep some older themes available, then we have a problem. Yes. This is the tricky part. We need to make sure the options are easy to understand, clearly defined and we pick good defaults. My biggest concern with this is doing it on a weblog by weblog basis, if we make this decision on a site-wide level then i think we will be in better shape. The idea in the current proposal is to support these options for upgraders: 1 - Turn on Atlas, completely turn off old model site.macromodel="roller_3.0_only" Velocity context loaded with only NEW model stuff Create weblog page shows only NEW themes This is the default for new installations I think this is a worthy option and should be the default for new installations starting with 3.0. 2 - Turn on Atlas, but continue to support old model site.macromodel=roller_3.0 Velocity context loaded with either OLD or NEW model stuff, depending on blog Create weblog page shows NEW themes only This is the default for upgrades Again, doing this on a blog by blog basis has me *really* scared. I am okay with this option as a site-wide option, but I see a lot of potential problems doing it blog by blog. 3 - Ignore Atlas page models and macros entirely You do this by leaving site.macromodel undefined (or setting to roller_2.0_only?) Velocity context loaded with only OLD model stuff Create weblog page shows only OLD themes ISSUE: Should we even support this option? ISSUE: Should frontpage weblog will work in this scenario? I don't think we need to support this option. IMO if we keep the 2 sets of macros and models completely independent then we can include both of them at the same time without problems. So I think upgrading systems should continue to get the legacy context stuff, but new installations don't. One Roller site can support both classic and Atlas themes, but I really want to avoid having themes that use a mix of classic and Atlas macros. A weblog MUST pick which macro/model it will use. I was going to use website.pageModels as a flag to indicate which macro/model, but perhaps that is too confusing. Instead, we could force weblogs to declare which version of macros should be used. website.macrosVersion=2.0 To be honest, I don't think this is realistic. I agree that this is the ideal way it would work, but I don't see it happening. We don't have any real way of ensuring that upgraded installations don't do something to make old template stuff available to weblogs that are set to use the 3.0 macros only. For weblogs that use the 3.0 model, we'd use website.pageModels to list all of the page models to be loaded (including the "main" $pageModel): website.pageModels - list of additional page models to add I agree with this, but for upgraded sites I think these are just added to the context in addition to the legacy stuff. Does that make sense? 3. I think we need to have a little more discussion about the feed urls. I didn't realize that the comment feeds needed to be available in both rss and atom, because that causes a problem with the current url proposal. If we are planning to offer each possible feed in multiple flavors (rss, atom, etc) then we need to plan for that a bit better. Best practice is to offer one feed format, so that's what I'd like Roller to do by default. Each weblog has two feeds: one for entries and one for comments. The feed format used by these feeds is determined by the weblog's website.feedType field, which may be either "atom_1.0" or "rss_2.0". Hmm, this one has me a bit worried as well. Why is it a best practice to only offer one type of feed format? Seems to me that only alienates some users who can only support either rss or atom, but not both. I prefer that we be able to support both feed types at the same time. Anyon
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
On 6/15/06, Dave Johnson <[EMAIL PROTECTED]> wrote: Thanks for the feedback. Lots of good suggestions there. On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > I think this looks good and will be a give improvement over what we > currently have. Here's a few notes/comments ... > > 6. You have a section called "Changes to existing POJOs" where you list > new methods to be added. This is the part I disagree with the most so > far. I don't think those methods should be added to our existing POJOs > because they are not related to the domain model in any way, they are > only related to the way we render our UI. I would much prefer to see > these methods be added to a class which extends the current pojos. This > also has the benefit that we don't need new methods for some things like > getTransformedText(), instead I think we should just override the > default pojos getText() method to return the transformed text. Yes. I like the idea of extending the POJOs. I'll update the proposal. On second thought, I'm not sure about this one. First, the new methods are related to our domain model. No matter what your context is, if you are calling the Roller interfaces and dealing with POJOs you're going to want to do things like getTransformedText() to get the plugin processed version of the entry. Transforming text is not part of the editor UI or the renderer UI, it's an operation that the entry should provide. For example, if you're writing a command line utility that calls the Roller interfaces to perform a system backup or weblog export, you'd need that method. Second, how do we go from a list of WeblogEntryData objects returned by the backend to a list of wrapped WeblogEntryDataEx objects? Do we do a copyFrom operation for each object? Do we extend the wrapper instead? Or do we just map the extended WeblogEntryDataEx object via Hibernate and persist it instead? Those aren't really appealing options. I don't like mixing UI into the POJOs either and I don't want to introduce any dependency on Servlet API or Struts or Velocity, but there are cases where POJOs need to know URLs and cases POJOs should be expected do rendering-related things (i.e. getTransformedText()). - Dave
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
Thanks for the feedback. Lots of good suggestions there. Comments inliine... On 6/14/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: I think this looks good and will be a give improvement over what we currently have. Here's a few notes/comments ... 1. I don't understand what "Page models return collections of POJOs" means. I don't consider that a requirement of a PageModel. I think a PageModel can return any type of object it wants. Can you explain what you meant by that? Aside from that I agree with your definition and what models we will have. You're right. Page models don't only return POJOs. I'll strike that. 2. I am a little uncertain about the whole website.pageModels and configuring different blogs with different models. I think this idea sounds good, but I am worried it's going to invite lots of problems, particularly for sites that are upgrading. Older sites are going to have a mix of old stuff on their site which needs to be supported, so I'm not sure we can really offer a weblog by weblog config option to alter the model. For example, what if someone upgrading from 2.x wants to keep some older themes available, then we have a problem. Yes. This is the tricky part. We need to make sure the options are easy to understand, clearly defined and we pick good defaults. The idea in the current proposal is to support these options for upgraders: 1 - Turn on Atlas, completely turn off old model site.macromodel="roller_3.0_only" Velocity context loaded with only NEW model stuff Create weblog page shows only NEW themes This is the default for new installations 2 - Turn on Atlas, but continue to support old model site.macromodel=roller_3.0 Velocity context loaded with either OLD or NEW model stuff, depending on blog Create weblog page shows NEW themes only This is the default for upgrades 3 - Ignore Atlas page models and macros entirely You do this by leaving site.macromodel undefined (or setting to roller_2.0_only?) Velocity context loaded with only OLD model stuff Create weblog page shows only OLD themes ISSUE: Should we even support this option? ISSUE: Should frontpage weblog will work in this scenario? One Roller site can support both classic and Atlas themes, but I really want to avoid having themes that use a mix of classic and Atlas macros. A weblog MUST pick which macro/model it will use. I was going to use website.pageModels as a flag to indicate which macro/model, but perhaps that is too confusing. Instead, we could force weblogs to declare which version of macros should be used. website.macrosVersion=2.0 For weblogs that use the 3.0 model, we'd use website.pageModels to list all of the page models to be loaded (including the "main" $pageModel): website.pageModels - list of additional page models to add Does that make sense? 3. I think we need to have a little more discussion about the feed urls. I didn't realize that the comment feeds needed to be available in both rss and atom, because that causes a problem with the current url proposal. If we are planning to offer each possible feed in multiple flavors (rss, atom, etc) then we need to plan for that a bit better. Best practice is to offer one feed format, so that's what I'd like Roller to do by default. Each weblog has two feeds: one for entries and one for comments. The feed format used by these feeds is determined by the weblog's website.feedType field, which may be either "atom_1.0" or "rss_2.0". 4. I'd like to suggest that the new WeblogPageModel have a different name. $pageModel doesn't mean anything to ordinary users, so picking something shorter and more descriptive would be good. I think the names for $config, $site, and $planet are all good. All the other context objects sound fine to me as well. How about $page or $roller? 5. I'm questioning if the WeblogPageModel should really provide methods for accessing entry, bookmark, category, and page collections. My take is that those things should be part of the Weblog pojo, so rather than construct a model and methods for that we should just giving the user access to their weblog and letting them use the pojo methods. Yes. I like that better. I'll update the proposal. 6. You have a section called "Changes to existing POJOs" where you list new methods to be added. This is the part I disagree with the most so far. I don't think those methods should be added to our existing POJOs because they are not related to the domain model in any way, they are only related to the way we render our UI. I would much prefer to see these methods be added to a class which extends the current pojos. This also has the benefit that we don't need new methods for some things like getTransformedText(), instead I think we should just override the default pojos getText() method to return the transformed text. Yes. I like the idea of extending the POJOs. I'll update the proposal. 7. I think the macros look pretty good except that I would prefer to see the
Re: Atlas proposals: Frontpage weblog and new Page Macro/Models
I think this looks good and will be a give improvement over what we currently have. Here's a few notes/comments ... 1. I don't understand what "Page models return collections of POJOs" means. I don't consider that a requirement of a PageModel. I think a PageModel can return any type of object it wants. Can you explain what you meant by that? Aside from that I agree with your definition and what models we will have. 2. I am a little uncertain about the whole website.pageModels and configuring different blogs with different models. I think this idea sounds good, but I am worried it's going to invite lots of problems, particularly for sites that are upgrading. Older sites are going to have a mix of old stuff on their site which needs to be supported, so I'm not sure we can really offer a weblog by weblog config option to alter the model. For example, what if someone upgrading from 2.x wants to keep some older themes available, then we have a problem. 3. I think we need to have a little more discussion about the feed urls. I didn't realize that the comment feeds needed to be available in both rss and atom, because that causes a problem with the current url proposal. If we are planning to offer each possible feed in multiple flavors (rss, atom, etc) then we need to plan for that a bit better. 4. I'd like to suggest that the new WeblogPageModel have a different name. $pageModel doesn't mean anything to ordinary users, so picking something shorter and more descriptive would be good. I think the names for $config, $site, and $planet are all good. All the other context objects sound fine to me as well. 5. I'm questioning if the WeblogPageModel should really provide methods for accessing entry, bookmark, category, and page collections. My take is that those things should be part of the Weblog pojo, so rather than construct a model and methods for that we should just giving the user access to their weblog and letting them use the pojo methods. 6. You have a section called "Changes to existing POJOs" where you list new methods to be added. This is the part I disagree with the most so far. I don't think those methods should be added to our existing POJOs because they are not related to the domain model in any way, they are only related to the way we render our UI. I would much prefer to see these methods be added to a class which extends the current pojos. This also has the benefit that we don't need new methods for some things like getTransformedText(), instead I think we should just override the default pojos getText() method to return the transformed text. 7. I think the macros look pretty good except that I would prefer to see the macros not have empty param lists unless they really don't need any variables to do their work. I think that any variable that is needed to do the work should be passed in (except for the utility classes). For example, #showBookmarkList($weblog). 8. I would also prefer that the #showWeblogEntryPager() macros *not* display the next/prev links as part of the macro. I think that functionality should be in a separate macro. Overall I think this is a very solid approach. As you work on the macros and page models I'd like to see them in the 3.0 branch so that I can actually see the code itself. I think the more people we have actually looking at that stuff the better so that we can try and spot potential pitfalls and ways we can keep things as tidy as possible. It's also more productive if we can watch and comment as progress is being made. -- Allen Dave Johnson wrote: I've already started implementation of the new Atlas frontpage proposal: http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_Atlas And today I posted the first draft of a new Atlas Page Macro/Models proposal: http://rollerweblogger.org/wiki/Wiki.jsp?page=ProposalAtlasMacroModels The new Atlas macro/models proposal is pretty significant. I'm proposing that we replace the old page models and macros that are used in all existing Roller themes with an entirely new set of models and macros. It's important that we get this right -- we don't want to have to do this again. The old system will still be available, but it will be possible to either 1) leave it in place, 2) leave it in place but not allow new blogs to use it or 3) to turn if off entirely. Please review and offer feedback. - Dave
Atlas proposals: Frontpage weblog and new Page Macro/Models
I've already started implementation of the new Atlas frontpage proposal: http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_Atlas And today I posted the first draft of a new Atlas Page Macro/Models proposal: http://rollerweblogger.org/wiki/Wiki.jsp?page=ProposalAtlasMacroModels The new Atlas macro/models proposal is pretty significant. I'm proposing that we replace the old page models and macros that are used in all existing Roller themes with an entirely new set of models and macros. It's important that we get this right -- we don't want to have to do this again. The old system will still be available, but it will be possible to either 1) leave it in place, 2) leave it in place but not allow new blogs to use it or 3) to turn if off entirely. Please review and offer feedback. - Dave
Re: Spam prevention proposals
I am up for the CAPTCHA comment authenticator for Roller 2.1 simply because it most widely used and easily recognize by other users from other web application environment. Dave Johnson <[EMAIL PROTECTED]> wrote: I added some specific proposals for spam prevention/management, some for Roller 2.1 and some for later releases: Each of these could/should be written up into a more detailed proposal/design, but I'd like to get some feedback first, if possible. - Dave Ransford Segu-Baffoe [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.noqturnalmediasystems.com/ - Yahoo! FareChase - Search multiple travel sites in one click.
Re: Spam prevention proposals
Lots of good stuff there. Here's a few additional thoughts based on how I have things prioritized in my mind ... Comment Management - I fully agree this should be done soon. Comment Moderation - Personally, I would push this further down the list. My belief is that most people don't want to hassle with approving every comment on their blog, plus I think it kind of devalues a weblog when you know your comments are being audited. I also think this won't actually reduce the amount of spam a weblog gets, only the amount that ends up on the weblog. A weblog that gets spammed to death may bury a user in approval notifications. Blacklist Management - I would like to see more stats on how effective this is before agreeing to continue using it, at least for comment and trackback spam. My belief is that the Math and Captcha authenticators is really all we need for comments, and the Trackback Validator is all we need for trackbacks. Referers are harder to deal with and maybe the Blacklist is the best bet in that case. Command-line database cleanup utility - Why make it command line? Why not include it in the webapp as part of the admin toolset? Disable referer display (site-wide) - I think this is a must. I believe this should be something done in the RefererManager implemenations and should allow site owners to define how they want their referer data used. Throttling - Very cool idea, but I agree this should be at the end of the list. Comments Newsfeed - I don't see why this is better than email notification, but fine. Trackback verification - I think this is a must and should replace Comment Moderation on the definite list for Roller 2.1. I believe that trackback spam represents the overwhelming majority of the spam we get today and this seems like the best way to fight it. Referer verification - This is harder because of the performance hit. You definitely don't want to do this on every request. The verification for trackbacks is okay because trackbacks happen only seldomly, but a referer verification would happen on all requests :/ Typekey authentication - Seems like a cool idea, but I agree this should also be very near the end of the line. So that's how I see it. The only real difference being that I think Trackback Verification should be done instead of Comment Moderation, and I think the cmdline tool should be built into the webapp instead. -- Allen On Fri, 2005-10-28 at 07:09, Dave Johnson wrote: > I added some specific proposals for spam prevention/management, some > for Roller 2.1 and some for later releases: > > > <http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_SpamPrevention> > > Each of these could/should be written up into a more detailed > proposal/design, but I'd like to get some feedback first, if possible. > > - Dave >
Spam prevention proposals
I added some specific proposals for spam prevention/management, some for Roller 2.1 and some for later releases: <http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_SpamPrevention> Each of these could/should be written up into a more detailed proposal/design, but I'd like to get some feedback first, if possible. - Dave
