Berkano Bookmarks

One of the main ideas behind starting Berkano - still far from mature unfortunately - provides a simple api to manage bookmarks: can be used to form navigation menus, in such a way that they're user customizable, for instance.

berkano-bookmarks

• navigation:
  • defines named menus (with "links" or "items")
  • each item can have other related items.
    > or an item can have one default children-item and all its childrens together would form the related items

• • There could be, for instance a "main" menu, which would define, the top-bar navigation of the site, for instance.
    But then you also have another menu named "photo tools", which would be refered to by its name, on the "photo_details" view, for instance.

• users could also have their own set of bookmarks (as a tree), self-manageable, or per group(s), manageable by super users

• implementations of the Bookmark interface
  • simple : a complete url (http://www.google.com), a name and a description.
  • dynamic : parameters in the url. could be stored, or given at runtime
  • internal : simple, but doesn't store the host nor context
  • dynamic+internal : uhuh
    Can't all these be a single impl ? > maybe not the dynamic one, if we want parameters at runtime.

• i18n ?

This is an idea that just popped up in my mind.

Instead of having fixed "tabs" and stuff, why not use a bookmark system?

Users will often want to have a homepage that groups different links they often use, but these might be too numerous to each be a "tab".

So I tought of the following:

• users should be able to bookmark any current page they're viewing
• users should also be able to bookmark any url.

This will come down to two types of bookmarks:

• external : for casual urls
• internal : for swaf "subapplications"

External urls will be dead easy to handle, and there will be no discussion about this (I guess)

Internal bookmarks, on the other hand, will raise a couple of questions:

• what should be stored? The url will probably be no good, because there's no guarantee that the url will still be valid, for example if the portal gets reinstalled with new subapplications, etc
• to what extend should context be stored? Should all request parameters be stored? This would probably lead to unwanted behaviour, because session attributes will be missing. And it's not wanted to save these with the bookmarks. (except maybe if we can make a clear separation between what needs to be stored and what doesn't, but this will make sub applications too tied to swaf; except if we find a way that apps can run outside swaf, but if they're swaf-aware, some session context stuff might be saved? ... All this sounds a bit bloated. Is this really needed? See below for more...
• users might want some context to be saved in their bookmarks, for example to have bookmarks for a search they often do. Could this eventually mean that only GET request parameters would need to be stored? Are they even separated in an HttpServletRequest?? (Maybe, like sort of proposed above, we would let swaf-aware applications/modules/actions declare what parameters they need stored with bookmarks, if they can be bookmarked, etc... ???)

Bookmarks can be grouped in folders, and, like in most modern browsers, there will be a special folder ("Bookmarks Toolbar Folder" in Firebird) which will make bookmarks in there appear in the "tab" area of the page header.

If the user's homepage is a blog/wiki, (s)he should be able to use a special "macro" that will display her bookmarks nicely. We should probably also foresee a SwafTags module for a SwafBookmarks tag.

– Main.gj - 17 May 2004