Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Merlin,
After your fundamental views module, I discover now your views bookmarks module. I have not yet installed it, but after reading its presentation it is certainly another very interesting idea.
Let me explain the sort of applications this reading inspire to me (at least to see if I have understood your explanations ;-).
1) I consider that blog entry, page, story (and may be forum topic which I have not yet used) could be the same content type (as defined by CCK) but with a different presentation (view and theme).
"Boolean attributes" (options, switches, flags, bookmarks here) added to the base content type (let's say page) will allow the author to decide if its page appears in the blog view, the story view and/or the forum view. The author (or a given role) could reclassify it afterwards easily. And more: if this is allowed and if I understand well, each user could decide what option he wants for himself. Wow!
2) As you mentionned, most of the publishing options of a node like Published, Promoted to front page or Sticky at top of lists could be considered as views bookmarks (if for example your two modules were incorporated into the core). Now administrators are able to add more flags like this. For exemple, with a proper theme, the author could decided to add "submitted by Username on Date" to his post (which is now done in /admin/themes/settings).
3) For the apllications above it seems that the term flags (options?) is more appropriate, more generic than the term bookmarks.
4) For a reader it will be very usefull indeed to have a bookmak this flag so he can list his bookmarks (favorites) with the view my_favorites_nodes. Do you think there is a way to bookmark categories (which are nodes with the category.module installed) and have a view of all the nodes assigned to the bookmarked categories? A sort of "second-level" bookmarking. For example to offer views like my_favorite_topics, my_favorite_places, my_favorite_photo_albums to users.
5) And why not flag/bookmark also users so that there could be a view like my_favorite_blogs? By creating automatically a node of type user (profile?) for each user or mixing uid and nid?
But before going too far, I should stop here my "request of features" and look how it works already by installing it!
Thanks again for all your contributions.
Jean.
Comments
Comment #1
merlinofchaos commentedThat's one way to do it; I don't think it's entirely the way I would do it but this is a functional method. Check out my writeup on this topic on my developer blog.
That doesn't even need to be in core. All that's needed is:
1) The flag to be available.
2) The flag to be meaningful.
Views Bookmarks does 1. For 2, you have to read it in theme. Now, there is a weakness in ViewsBookmarks regarding 2 that you've just made me think about; a weakness that is easily rectified. The list of bookmarks isn't actually loaded into the node. But a short piece of nodeapi code could fix that relatively easily. In that case, it becomes very easy to make the flags meaningful in ways that are not just content organization (i.e, Views).
Absolutely, but no one would ever find the module. =)
When category module gets Views integration, this would be possible.
Primarily because Views doesn't actually know how to do proper user lists. That's a future extension to views. The query builder can handle it, but there's the data required. Maybe some enterprising soul would like to write User Views -- there's a lot of value in it. The other issue there is that you mention blogs, but I think blogs should be nodes, not just purely attached to users.
Comment #2
Montuelle commentedThank you Merlin for your answer.
1) I have been to your site. Very instructive. I have left (another) comment there.
2) I mentionned "in core" because Published, Promoted to front page or Sticky at top of lists were already in core. Defining them in an external module would have duplicated them.
3) I ment Views Flags rather than Views Bookmarks.
5) I agree with you: blog entries are nodes. But for constructing the view blogs_of_my_favorite_authors it seems that I have to bookmarks my favorite authors (if this was possible of course).
Comment #3
Montuelle commentedMerlin,
I have now installed the views_bookmarks module and played with it. It is not completly what I imaged in the point 1 and 2 of my first post above ... but it is not very far.
It is, of course, well designed for bookmarks (favorites). But it is less adapted for flags (options) which an author could toggle when he is creating or editing a node (like Published, Promoted to front page or Sticky at top of lists already existing in the core).
Of course the adminstrator of views_bookmarks can create such flags for the content type he wants. Then any user having the right role can click on the link when is viewing that node to toggle the flag. But restricting that permission to only the node owner (and administrator) is not possible.
You may say that for doing this I should use Flexinode or CCK. But I don't want to edit several node types. It should be possible to add/substract easily (boolean) properties to existing node types for controling views (as easy it is to add Taxonomies from one or two admin forms).
To be able to have such flags available when creating/editing a node (like the ones in publishing options), it seems to me that only two things have to be done:
1) In /admin/views_bookmark/edit/1 replace the Teaser checkbox by 3 checkboxes:
Like this it is possible to show the flag only in creating/editing mode. And only users allowed to enter in these modes will be able to modify it (if they have also the right role for bookmarks).
2) In /node/add/content-type and /node/##/edit, for all the content-types allowed and having the Create/Edit option, add a collapsible fieldset with a checkbook for each flags.
Voila!
I know that your module was mainly issued as an exercise to show the functionality of the Views module, but it seems to me that it could be more than that. I have no idea of how difficult it is to implement such a feature. Already with only the bookmarking it is certainly useful and powerfull. Thank you again for it.
Jean
Comment #4
merlinofchaos commentedThis is not that difficult of a feature. It'll need a little text to make it clear that using that bookmark while editing is only useful if it's a 'global' bookmark, but I think form validation can cover that.
Comment #5
Montuelle commentedI don't think it should be "forced" to global.
Let's take the example of "publish on the front page". The author decides so but a reader may decide, once the reading done that the post is not interesting and thus unflag it so he will not see it there again.
Comment #6
merlinofchaos commentedAhh now that's an interesting idea, but that simply can't work with the existing system.
Bookmarks like this are either global OR user based, but you have a combination of both. What you are looking for is a 3 state value: true, false, default. If default, look at the global setting. That's a pretty significant difference, unfortunately.
Comment #7
Montuelle commentedThank for your explanation. I realize now my mistake:
The administrator always creates the flag. By definition it is in default state. When a node is created the flag gets that default. After that authorized users can toggle it.
So I you can do what you propose in #4 it will be very good.
If you implement it, by using two flags: one global publish on the front page (for the creator of the node) and one non global hide this for each reader, I will be able to do what I wanted to do! It's not a trick, in fact it's THE solution that I should have found first.
Thanks again for your fast and always constructive answers.
Comment #8
quicksketchBookmark while creating/editing a node is now a feature in 1.x. 1.2 will be released shortly.
Comment #9
(not verified) commented