Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Excerpt

One of the main ideas behind starting swaf - 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.

Code Blockpanel
titleSome old ugly wiki page

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

  • 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
  • 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(wink))

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