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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- ****************************************** * Scott T. Weaver * * <[EMAIL PROTECTED]> * * <http://www.einnovation.com> * * -------------------------------------- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEditPro, Website Content Mangement * * <http://www.openeditpro.com> * ****************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
