Thanks. That is a good example and it explains the alternatives well. My concern is requiring people to "just directly modify the template" because on some sites users are not allowed to edit the templates (e.g. blogs.apache.org). Without the bookmark folder (or some other grouping concept) the "allow blog Authors to add new links to multiple bookmarks lists" cannot be supported when template edits are turned off. (I actually need this use case to support one of my blogs.)
- Dave - Dave On Sun, Jan 12, 2014 at 4:36 PM, Glen Mazza <[email protected]> wrote: > OK, a design which allows for named bookmark categories/folders while not > allowing subfolders underneath them would be acceptable. I.e., a user > creates three categories of bookmarks: Sports, Travel, News, with several > links underneath each, but no need for additional subcategories under those > top-level categories. > > So, my suggestion, vetoed by you, is (A): > > --- nhl.com > --- nba.com > --- nfl.com > --- visit Florida > --- visit Las Vegas > --- visit Hawaii > > You would accept this instead: > > Sports > --- nhl.com > --- nba.com > --- nfl.com > > Travel > --- visit Florida > --- visit Las Vegas > --- visit Hawaii > > What we currently have is C: > > Sports > --- general sports link #1 > --- general sports link #2 > Football > --- football link #1 > --- football link #2 > College Football > --- college football link #1 > --- college football link #2 > Basketball > --- basketball link #1 > --- basketball link #2 > Travel > North America > --- Las Vegas travel! > --- California travel! > South America > --- Argentina travel! > > So you would accept an architectural change from from (C) to (B) but not > (C) to (A). I agree that (B) is better than (C), but (B) to be done right, > should probably use two tables instead of one (bookmark and > bookmark-category). While (C) should probably be reimplemented as (B), > there's not much of a difference between the two for me to put in the > effort; so I think I'll pass on this for the time being and look at other > issues instead. While (B) looks nicer than (A), I just would never use the > Bookmarks page personally to implement (B), again, I just directly modify > the template and add/maintain my links there directly in however many > different groups I want. > > Thanks, > Glen > > > On 01/12/2014 03:06 PM, Dave wrote: > >> -1 to removing the ability to group bookmarks. I think it's very useful >> to >> be able to have named groups of links. I rely on that feature in several >> themes that I have developed. >> >> I think we need a way to group bookmarks in "folders" but we do not need >> the ability to have sub-folders, i.e. folders within folders. >> >> - Dave >> >> >> >> >> On Sat, Jan 11, 2014 at 8:05 PM, Glen Mazza <[email protected]> wrote: >> >> Hi team, once Gaurav's patch removing blog subcategories is in place, and >>> the simplifications this switch incurs realized, I'd like us to do the >>> same >>> with our blogroll page--namely, remove sub-bookmarks (bookmark folders) >>> and >>> incorporate blogitem ordering in its place. I imagine the blogroll page >>> will look closely similar to the (upcoming) category page -- a straight >>> list of top-level blogroll items and up-and-down arrows of some sort to >>> facilitate ordering of them. As part of this switch, we'll be pulling >>> out >>> the "Import bookmarks via OPML" option, as few use OPML and its value is >>> greatly shrunk once we move from a tree to a list for blogroll items. >>> This >>> change will also result in the bookmark table being simplified from a >>> hierarchical to a flat structure (i.e., no more parent bookmark column), >>> just as is being done with categories. >>> >>> The blogroll page is primarily for novice and intermediate bloggers and >>> nearly all of them would be fine with a single-list of blogroll items, as >>> indeed virtually all blogrolls are formatted as lists anyway. The >>> handful >>> of more advanced users looking into maintaining a tree of blogroll links >>> can still accomplish that via template modifications (manually adding the >>> HTML links into the side-column template), an approach many would be >>> taking >>> even if trees continue to be supported in the blogroll page. (I never use >>> the blogroll page myself, I just manually configure my blogroll links in >>> the side column template anyway along with the formatting I desire.) So >>> I >>> think this change will nicely tighten up and further simplify the Roller >>> code and UI, helping increase its adoption, while not preventing blogroll >>> trees for the relative few wanting them. >>> >>> WDYT? >>> >>> Regards, >>> Glen >>> >>> >>> >
