portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject [J2] Layout, navigation and decoration (Was: [J2] Menu implementation)
Date Fri, 02 Jul 2004 01:32:54 GMT
After some discussions I had with David Sean Taylor and some more thinking of
myself I like to come up with another more detailed, and also somewhat
simplified, proposal for the portal navigation based on my previous Menu
implementation proposal and the earlier proposed Layout and Decoration proposal.

For now, I still resort to a mail based proposal. Tried the wiki but don't feel
comfortable with it yet. Once this is all over and we have reached consensus on
how to proceed I'm more than happy to add it to the wiki and keeping it in sync
with the actual implementation. For that, I think wikis are great.

First a few traceback links where this one is based upon:
  - 1) current J1 impl
  - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf
       also (partly) available on the wiki:
  - 3) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=14232
       ([J2} Proposal for Layout, pages & Decorator handling in J2)
  - 4) http://nagoya.apache.org/jira/browse/JS2-69
       (Finalizing Portal Navigation using the Profiler)
  - 5) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=15318
       ([J2] Menu implementation), the original start of this thread
  - 6) http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=15433
       Message in which I entered my initial proposal,
       also available on the wiki:

To make one thing clear, in this, as well as my previous proposal, I tried to
capture the ideas and input of many others, so credit for these goes too
all involved :-)

Basis for this proposal:
- keep it as simple as possible so we can get something implemented soon, and
   not continue discussing things till the end of the year without any result
- recognition of what is required in the end and what will do for an initial

* Required features / functionality (in the end) *
Below I have a list of requirements I have captured from all the discussions and
information above so far (including some personal discussions).
I don't think this list is complete and possibly is incorrect in some places.
Furthermore, the ordering is more or less arbitrarily.
Please comment, correct and extend as much as possible. I think this list is
really important to get complete!
Note: further down I present a 'lighter' version for an initial implementation.

  1) Replace "bag of pages" with a hierarchical structure using Folder Nodes
     and Page leafs.
  2) Pages are endpoints (leaf) in navigation: no fragment navigation (like in
     Fragment navigation or portlet navigation can be implemented using different
  3) Folder navigation implicitly leads to Page navigation: the portal will
     automatically select the "default" or first page.
  4) Support J1 Profiler page lookup functionality using derived (or
     specified) capability, mimetype, language.
  5) No embedded Page navigation (J1 menus) but Folder context based navigation.
  6) Support external (url) links, as well as symbolic links (references) to
     other Folders and Pages within a Folder for inclusion in navigation menus.
  7) Provide a hardcoded, default (simple) navigation configuration for the
     portal like one tabbed top menu showing only the current Folder contents.
  8) Allow for override of default (natural) ordering and hiding of Folder and
     Folder content (Pages, Links, References) through meta-data on each element.
     Customization thereof by an end user will be stored in user preferences and
     not in the meta-data.
  9) Keep required meta-data to the utmost minimum, using defaults and
     inheritance as much as possible.
10) Use Velocity or JSP templates for layout and navigation rendering as well as
     portlet (window) dressing.
     Use css styles and logical image references for decoration (skins).
11) Allow for easy site structure definition (using a portlet): add, remove and
     move folders, pages, links and references.
12) Allow for easy configuration/customization (using one or more portlets) of:
    1) Outer page layout: portal headers, footers.
       Not sure about this one though, maybe it always could/should remain a
       fixed/hardcoded template?.
    2) Navigation (menus):
       1) type (tabbed, tree, dhtml pulldown etc)
       2) position: top, left, right, bottom (remember Lotus 123 ?)
       3) starting (folder) level: root or 0, current, specific like "3"
       4) depth: number of (folder) levels to render
       5) item ordering and hiding
    3) Portlets (fragments) layout: rows, columns
    4) Skins (decoration): css styles and logical images references
       1) outer page layout skins
       2) navigation (menu) skins for each menu type
       3) portlets layout skins
       4) portlet skins
    5) Access constraints (security) based on roles/privileges for site structure
       elements (Folder, Page, Link, Reference, Portlet/Portlet Fragment).
       Also for related meta-data elements restricting certain configurations
       like allow/disallow modification of a certain Folder its navigation
       definition, skin, layout, etc.
    6) Support inheritance for all above. Only complete overrides should be
       supported. Allowing override only on property level (like menu depth) will
       probably be too complex.
13) All customizable configurations require meta-data definitions.
     For instance, skins must be defined in meta-data and the resulting css
     styles and image references dynamically rendered (or precompiled and
     stored/cached in the repository/file system). Another option would be using
     a css/javascript parser/editor (much more complex/difficult to support I
14) Support import/export and api manipulation of all (or most) above,
     preferably using an open standard like JSR-170.
15) Allow all meta-data to be referenced by unique id (thus requiring also
     requiring an unique id on Folders and Pages).
     This is required to allow api manipulation/support conform JSR-170
     and/or probably other standards/storage models as well.
16) Allow for different storage models (file system, DAV, CMS, DB)
17) ...

* Decorators and Skins *
In the current layout and decorator handling proposal (see link 1 above) a page
is rendered with a layout (page) decorator and a portlet decorator.
Both these decorators apply a certain embedded/hardcoded style and images to the
decoration they render which I like to call a Skin.
I propose to redefine this with 4 types of decorators: outer page, navigation,
inner page (portlets layout) and portlet decorators. Furthermore, I like to
separate/abstract the skin used, and allow for other customizations as well.
Although this might seem an increase in complexity I think it will actually
reduce it as result of a better dividing of responsibilities.

Decorators are special templates located in 4 named folders mapping:

Each of these folders contain one subfolder for each specific decorator
and additional subfolders beneath for each supported skin (optional):

Each decorator will define its own set of default properties and skin to be used
if not overridden (if even possible).
Each decorator *can* allow for customization of the used skin and possible other
properties like the title and or footer text to be used by the page decorator.
Supported decorator properties and skin definitions must be defined in meta-data
so a customization portlet can be used to change these. A skin customizer should
allow modification of supported style properties (like colors) and can allow
image upload to override default images.

Decorators should *not* define default properties for lower level decorators
(like a page decorator defining properties for layout or portlet skins).

The page, navigation and portlet decorators all can be inherited: they are
dynamically determined by first looking at a configuration at the Page, then its
Folder and then upwards in each higher Folder until the root Folder. If then
still no configuration is found the default configuration defined for the whole
portal will be used.
I don't see much use of inheritance for the layout decorator. I expect the
layout of the portlets on a Page to be Page specific. If inheritance is to be
allowed, changes on a higher level could lead to unexpected and unwanted layout
changes to Pages below. I thus propose overriding the default layout (like all
in one row or all in one column) only be possible on a Page itself.

Configuring the decorators involves specifying one or more of each type to use,
optionally with an override of the skin to use.

    <decorator type="page" name="jetspeed" skin="orange"/>

    <!-- a dhtml pulldown menu displaying first level content as tabs and direct
         subfolders (level 1) content in pulldown menus
    <decorator type="navigator> position="top" name="pulldown" skin="blue">
      <property name="level" value="0"/>
      <property name="depth" value="2"/>

    <!-- a left side tree menu showing all items from folder level 2 down -->
    <decorator type="navigator position="left" name="tree" skin="blue">
      <property name="level" value="2"/>
      <property name="depth" value="-1"/>

    <decorator type="layout"  name="two columns" skin=""/>
    <decorator type="portlet" name="jetspeed" skin="metal">

 From the above example it becomes clear multiple navigation decorators are
possible. I propose supporting 4: top, left, bottom and right menus.

If on a certain level (Page or Folder) one navigation decorator is specified,
only those specified will be used. So, if only a top position navigation
decorator is specified no others will be rendered even if on a higher level
others are defined (like in the above example a left side tree menu).

* Rendering *
My proposal for the page rendering is done as two nested java.awt.BorderLayout
like tables:

1) the page decorator renders a (standard if not customizable) page border or
frame, allowing for a header, footer, and/or left and right column.
2) Nested within the page frame the navigation decorators render one or more
menus to the top, left, bottom and/or the right.
3) Nested within the navigation frame the layout decorator renders the
portlet(s) defined for the Page (Portlet Fragments).
4) The portlets are each rendered by their portlet decorator (which may be an
overridden one, defined on the Fragment).

This is almost the same rendering structure as used right now, extended with the
navigation frame.

* Initial version *
The above proposal is a very flexible one I think, but one which will take quite
a lot of work to implement fully.
To be able to get *something* working soon I suggest we start with an lighter,
less flexible initial version. Later extensions should build upon this version
and not involve major rewrites though.
This initial version is *not* yet targeted for the first formal release of J2.

I suggest to *not* or only partly implement the following features in the
initial version:
  4) No Profiler based capability, mimetype or language page lookup
     Yes: I know this one is very important to support but it will complicate
     the creating Folder/Page navigation a lot. I should be no.1 priority to get
     implemented right after we got the initial version working.
     It *must* be implemented for the first J2 release.
     Can't leave out WML now, can we :-)
  6) No external links (url) and references to Folders and Pages
  8) No ordering and hiding of navigation items
11) No moving of Folders and Pages.
12) Customization/configuration:
     1) Customization of outer page layout. Different page decorators should be
        supported though.
     2) Navigation:
        1) All kind of menu decorators. Only one or two simple ones.
        5) No ordering and hiding of menu items (same as 8) above)
     6) No access constraints/control on meta-data modification.
13) Only limited customizable configurations (or maybe none at all). Certainly
     no skin customizing yet.
14) No import/export. Probably no formal open standard api support like JSR-170
     (its not even final yet). Keeping future support in mind is very important
16) Only a file system implementation (xml based)

One final note: I'll be going on a two weeks holiday this saturday. I probably 
have only limited access to internet/mail. If I can get to it I'll notify it on
the list, otherwise expect a two weeks delay of feedback from my side :-)



To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message