Scott T Weaver wrote:
Maybe this is because I didn't make my idea clear enough. Furthermore, our current (J2) structure might also add to the confusion.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 ;)
First of all, to me the distinction between a page and a layout decorator is crystal clear: their responsibilities are completely different. Of a page decorator I expect usually one one to be used by a portal instance (one standard heading/footer/style). The layout decorator though is really page based and contained portlets related (I even require it as such, no inheritance other than from the portal default). So, mixing these two in one decorator really is kinda strange to me.
But, maybe your view what a layout decorator is is somewhat different.
What I mean with layout decorator is a very, very simple decorator: its only responsibility is rendering the root portlet fragments from the Page psml in a certain table structure.
But, in J2 root portlet fragments usually (at least in our current example psml files) are 'layout' portlets, defining a 'layout' for nested portlet fragments themselves. And we need these 'layout' portlets if we want to allow nested table layouts. Furthermore (as I understood it), these 'layout' portlets are used during an initial run of the PageAggregator to determine which portlets are to be rendered, allowing for optimization by skipping non-visual/hidden/non-accessible portlet during the real render run.
Thus, if there would always be one root portlet fragment the layout decorator in my definition would be kinda useless (how many ways can you layout one element in one cell). Only for border and/or padding style definition this would be overkill.
But if multiple real portlet root fragments (not of 'layout' kind) are defined the layout decorator makes much sense.
So, we can choose to drop the layout decorator and have all portlet layout be handled by 'layout' portlets. Then we must require a single root 'layout' portlet. I would be fine with that.
But, what about skin (or only css style) definitions for these 'layout' portlets? Currently (AFAIK) we don't have/support those. Should we have them?
Shouldn't we call these 'layout' portlets the layout decorators which happen to be portlets? (note: then these represent a tree of layout decorators).
Hope this clears up my position.
Other than that I am +1 on everything.
Thanks!
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
