portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott T Weaver <scotts-jetspeed-l...@binary-designs.net>
Subject Re: [J2] Layout, navigation and decoration (Was: [J2] Menu implementation)
Date Fri, 02 Jul 2004 19:30:18 GMT
Everything looks great, Ate!  Except I am having difficulty coming up
with a use case that needs both a page and a layout decorator.  I am not
saying no, I would just like a solid case were this is more useful then
confusing ;)

Other than that I am +1 on everything.

On Thu, 2004-07-01 at 21:32, 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
-- 
******************************************
*           Scott T. Weaver              *
*         <weaver@apache.org>            *
*     <http://www.einnovation.com>       *   
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


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


Mime
View raw message