portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [J2] Layout, navigation and decoration (Was: [J2] Menu implementation)
Date Fri, 02 Jul 2004 22:04:05 GMT


Scott T Weaver wrote:

> 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 ;)
Maybe this is because I didn't make my idea clear enough. Furthermore, our 
current (J2) structure might also add to the confusion.

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: jetspeed-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


---------------------------------------------------------------------
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