You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Scott T Weaver <sc...@binary-designs.net> on 2004/07/02 21:30:18 UTC
Re: [J2] Layout, navigation and decoration (Was: [J2] Menu
implementation)
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 *
* <we...@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
RE: [J2] TestSimpleDeployment Failing
Posted by Jeremy Ford <ca...@hotmail.com>.
I dived into this and I still don't know what to do about it. Maybe Scott
will know more. Here's what I've found so far:
During the TestSimpleDeployment, a JarFileSystem is created based off of the
demo.war. This file system contains an open jarfile. If one closes the
file system, this will close the jarfile, thus allowing you to delete the
file. However, if you close the file system, you cannot redeploy the same
app because of a cache in VFS which still points to the now closed file
system.
This explicitly closes a file system:
((VfsComponent)fileObj.getFileSystem()).close();
but, leaves it in the FileSystemManager cache.
There is a method on the manager that once can use to free up resources. I
think this is the preferred method. It is called by:
((DefaultFileSystemManager)fsManager).freeUnusedResources();
However, the file system keeps a count off accesses to the resources within
the file system. It will not release sources if the number of access is
greater than zero. You can decrease the number of access by calling close
on the objects that you access. I modified the code to call close, but this
did not solve the problem. Within the test, there is a method called
copyDeployables. This method uses a VFS method (copyFrom) to copy the files
necessary for the test to run. During this, the number of accesses are
increased by VFS's own methods. The number never decreases because they do
not call close (or anything that might decrease the access #).
Basically, I can get parts of the test to work, but I can't get the whole
test to run. I'm not sure that the FSManager that is used for copying
should be used for the J2 deployment test. I've tried to create a brand new
FSManager at the start of the TestDeploy, but, during the course of the run,
the second attempt to delete the demo.war will fail instead of the first.
Jeremy Ford
jford@apache.org
-----Original Message-----
From: David Sean Taylor [mailto:david@bluesunrise.com]
Sent: Monday, July 05, 2004 11:46 AM
To: Jetspeed Developers List
Subject: Re: [J2] TestSimpleDeployment Failing
The test fails on Windows, succeeds on Linux
For now I exclude test here in order to build until I can find some
time to find the resource leak
I believe this unit test isolates the un-deploy issue on Windows
(un-deploy fails on Windows, succeeds on Linux)
On Jul 5, 2004, at 9:37 AM, David Le Strat wrote:
> Is any else having the same issue.
> TestSimpleDeployment is failing with the latest head.
>
> Regards,
>
> David.
>
> Testcase:
> testDeploy(org.apache.jetspeed.deployment.TestSimpleDeployment):
> FAILED
> HW_App was not removed from the registry.
> junit.framework.AssertionFailedError: HW_App was not
> removed from the registry.
> at
> org.apache.jetspeed.deployment.TestSimpleDeployment.verifyDemoAppDelete
> d(TestSimpleDeployment.java:233)
> at
> org.apache.jetspeed.deployment.TestSimpleDeployment.testDeploy(TestSimp
> leDeployment.java:192)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
> va:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
> rImpl.java:25)
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> 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
david@bluesunrise.com
[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
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Maven Plugin Issues
Posted by Scott T Weaver <sc...@binary-designs.net>.
Hi David,
Try deleting all of the .cache files in .maven/plugins, that may fix
your problem.
On Mon, 2004-07-05 at 13:49, David Le Strat wrote:
> Hello there,
>
> I am trying to build J2 but keep bumping into:
>
> BUILD FAILED
> File......
> C:\tools\eclipse\workspace\jakarta-jetspeed-2\maven.xml
> Element... maven:reactor
> Line...... 318
> Column.... 40
> Unable to obtain goal [deploy-plugin] --
> C:\tools\eclipse\workspace\jakarta-jetspeed-2\maven-plugin\maven.xml:52:43:
> <attainGoal> No goal [plugin:deploy]
> Total time: 3 minutes 36 seconds
> Finished at: Mon Jul 05 13:44:30 EDT 2004
>
> Has anyone any idea what could be the cause of this
> problem?
>
> I am using the latest head on WinXP with Maven RC3,
> basically following the latest getting started.
> Between this and a couple broken tests, I am having a
> rough time getting back into J2. Quite a bit has
> happened in a couple weeks time ;)
>
> David.
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
--
******************************************
* Scott T. Weaver *
* <we...@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
[J2] Maven Plugin Issues
Posted by David Le Strat <dl...@yahoo.com>.
Hello there,
I am trying to build J2 but keep bumping into:
BUILD FAILED
File......
C:\tools\eclipse\workspace\jakarta-jetspeed-2\maven.xml
Element... maven:reactor
Line...... 318
Column.... 40
Unable to obtain goal [deploy-plugin] --
C:\tools\eclipse\workspace\jakarta-jetspeed-2\maven-plugin\maven.xml:52:43:
<attainGoal> No goal [plugin:deploy]
Total time: 3 minutes 36 seconds
Finished at: Mon Jul 05 13:44:30 EDT 2004
Has anyone any idea what could be the cause of this
problem?
I am using the latest head on WinXP with Maven RC3,
basically following the latest getting started.
Between this and a couple broken tests, I am having a
rough time getting back into J2. Quite a bit has
happened in a couple weeks time ;)
David.
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] TestSimpleDeployment Failing
Posted by David Sean Taylor <da...@bluesunrise.com>.
The test fails on Windows, succeeds on Linux
For now I exclude test here in order to build until I can find some
time to find the resource leak
I believe this unit test isolates the un-deploy issue on Windows
(un-deploy fails on Windows, succeeds on Linux)
On Jul 5, 2004, at 9:37 AM, David Le Strat wrote:
> Is any else having the same issue.
> TestSimpleDeployment is failing with the latest head.
>
> Regards,
>
> David.
>
> Testcase:
> testDeploy(org.apache.jetspeed.deployment.TestSimpleDeployment):
> FAILED
> HW_App was not removed from the registry.
> junit.framework.AssertionFailedError: HW_App was not
> removed from the registry.
> at
> org.apache.jetspeed.deployment.TestSimpleDeployment.verifyDemoAppDelete
> d(TestSimpleDeployment.java:233)
> at
> org.apache.jetspeed.deployment.TestSimpleDeployment.testDeploy(TestSimp
> leDeployment.java:192)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
> va:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
> rImpl.java:25)
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - You care about security. So do we.
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> 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
david@bluesunrise.com
[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
[J2] TestSimpleDeployment Failing
Posted by David Le Strat <dl...@yahoo.com>.
Is any else having the same issue.
TestSimpleDeployment is failing with the latest head.
Regards,
David.
Testcase:
testDeploy(org.apache.jetspeed.deployment.TestSimpleDeployment):
FAILED
HW_App was not removed from the registry.
junit.framework.AssertionFailedError: HW_App was not
removed from the registry.
at
org.apache.jetspeed.deployment.TestSimpleDeployment.verifyDemoAppDeleted(TestSimpleDeployment.java:233)
at
org.apache.jetspeed.deployment.TestSimpleDeployment.testDeploy(TestSimpleDeployment.java:192)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Layout, navigation and decoration (Was: [J2] Menu implementation)
Posted by Ate Douma <at...@douma.nu>.
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