portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] Layout, navigation and decoration (Was: [J2] Menu implementation)
Date Fri, 02 Jul 2004 16:37:40 GMT
I already reviewed this Ate
Im +1 on the proposal, and Im OK with my requirements being implemented 
in a 'phase II'

On Jul 1, 2004, at 6:32 PM, Ate Douma wrote:

> 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:
>       http://wiki.apache.org/portals/Jetspeed2/LayoutsAndDecorations
>  - 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:
>       http://wiki.apache.org/portals/Jetspeed2/PortalNavigation
> 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
>   implementation
> * 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
>     J1).
>     Fragment navigation or portlet navigation can be implemented using 
> different
>     pipelines.
>  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
>     expect).
> 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:
>   /WEB-INF/decorators/page
>   /WEB-INF/decorators/navigation
>   /WEB-INF/decorators/layout
>   /WEB-INF/decorators/portlet
> Each of these folders contain one subfolder for each specific decorator
> and additional subfolders beneath for each supported skin (optional):
>   /WEB-INF/decorators/page/jetspeed
>   /WEB-INF/decorators/page/jetspeed/skin/orange
>   /WEB-INF/decorators/page/jetspeed/skin/orange/images
>   /WEB-INF/decorators/page/jetspeed/skin/blue
>   /WEB-INF/decorators/page/jetspeed/skin/blue/images
> 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.
> Example:
>    <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"/>
>    </decorator>
>    <!-- 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>
>    <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
>     though.
> 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 
> :-)
> Regards,
> Ate
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

David Sean Taylor
Bluesunrise Software
[office]   +01 707 773-4646
[mobile] +01 707 529 9194

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

View raw message