Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Subject: Re: [J2] Menu implementation
From: Scott T Weaver <scotts-jetspeed-list@binary-designs.net>
To: Jetspeed Developers List <jetspeed-dev@jakarta.apache.org>
In-Reply-To: <40CF7815.3010809@douma.nu>
References: <40CF1B72.8090307@douma.nu>
	 <45B5E6E0-BEF0-11D8-BCF6-000393C78E78@bluesunrise.com>
	 <40CF7815.3010809@douma.nu>
Content-Type: text/plain
Message-Id: <1087392717.3409.65.camel@pnqnp008-und538547.net.plm.eds.com>
Mime-Version: 1.0
Date: Wed, 16 Jun 2004 09:31:59 -0400
Content-Transfer-Encoding: 7bit

On Tue, 2004-06-15 at 18:28, Ate Douma wrote:
> David Sean Taylor wrote:
> 
> > 
> > On Jun 15, 2004, at 8:53 AM, Ate Douma wrote:
> > 
> >> I've been trying to get a clear picture of what the options and 
> >> positions are about menu creation for J2.
> >>
> >> I'm quite lost after reviewing several sources:
> >>  - 1) current J1 impl
> >>  - 2) design-docs/src/decorations/J2 layout and decorator handling.pdf,
> >>  - 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)
> >>
> >> A few design issues needs to be addressed I think to be able to decide 
> >> on the impl. of menus.
> >>
> >> - Nested pages
> >> Should these be allowed?
> >> Part of that question is what a Page is.
> >> The pdf (see 2) says its to be considered a Fragment.
> >> If this is meant as a "fragment" which can be included, alright. But, 
> >> I don't see how it also can
> >> be a "Fragment" (note the case) or why it should be made one.
> >>
> >> Fragments already can contain other Fragments though. This is more or 
> >> less in analogy to nested
> >> portlets in J1 I belief.
> >>
> >> Maybe one reason why one would want to nest pages is to be able to 
> >> define different decoration on a nested page.
> >> It has been suggested by Scott (see 4) to allow for the most flexible 
> >> way possible this should be possible
> >> (even up/down overrides if needed).
> >>
> > I see pages as existing in a bug bucket of pages.
> > Its up to the profiler to locate the page.
> > The way this is implemented in J2, the profiler looks at the URL path to 
> > find the page.
> > For example
> > 
> > /jetspeed/portal/pam
> > /jetspeed/portal/struts-demo
> > 
> > Locates a page named "pam" and "struts-demo" respectively
> > A believe that the Jetspeed Profiler should support locating pages in a 
> > CMS-like URI namespace:
> > 
> > /jetspeed/portal/root/folder1/folder2/mypage
> I think this is already possible right now, although not really based on a "Folder" object.
> 
> > 
> > Would locate a page name "mypage" in the folder "/folder1/folder2"
> > 
> > This does not imply that pages can be nested, and Im against nesting 
> > page as it corrupts the semantics of a page version a fragment.
> > The page implementation should support 'nesting' or 'referencing' of 
> > fragments.
> > A fragment should also be referenced in the portal URL, for example as a 
> > render parameter:
> > 
> > /jetspeed/portal/folder3/page4/_r_fragment/3939
> > 
> > 
> >> To me, this seems to lead to very complex psml though. I would 
> >> certainly like to see a more
> >> simple model implemented first before going that road.
> >>
> > Im -1 on nested pages, and +1 on nested fragments (references), which 
> > does not need to be implemented in the first solution
> +1
Also -1 on nested pages.

> Nested fragments, but not as references, are already used by the layout portlets!
I would also like to add support for non-portlet fragments, like raw
html, etc.

> 
> > 
> >> Probably the same result could be created without page nesting using 
> >> fragment references. These could
> >> reference other pages (pulling in their decorator definitions with 
> >> them) or fragments within other pages.
> >> As far as I can tell, then there would be no need to define pages 
> >> within pages.
> > 
> > 
> > Fragments do not need to be associated with a page, at least not in a 
> > database implementation
> > See the database model for PSML in the J2 CVS
> I think if we are going to support non-page based fragments (for references)
> we should also provide a file based implementation. Dunno if you should still
> call it psml then though.

Believe it or not, I am beginning to think the non-RDBMS XML file-based
page system is a better approach than the RDBMS one.  It fits better
into CMS model than an RDBMS page manager does.  We could also use VFS
to abstract the file system were the pages reside.  VFS also supports a
WebDAV based file system out the box.


> 
> > 
> > I believe the page within a page concept can be easily supported via the 
> > profiler's portal URI space, a CMS-like tree
> Using folder semantics you mean? Then I'm +1.
I also think the folder metaphor is the best approach.

> > 
> >>
> >> - Folder or menu elements
> >> The Folder concept containing other folders and/or pages could be used 
> >> to generate menus as proposed by Scott (see 4).
> >> Something I'm missing right now is a clear understanding how/where 
> >> folders are defined. I found the om impl but no usage
> >> yet so its something I can't relate to enough yet to really decide if 
> >> I'm going to like it or not.
> >>
> > Couldn't the Page Manager support the concept of folders in its model?
> > Im also wondering if the Page Manager should support the JCMS API
> One thing at a time please ;-)
> Do I understand it now correctly that folders (for a file based Page Manager)
> are simply derived from filesystem folders? 
That is how I see it.  Or possibly using a VFS file system.

> So no definition needed in the psml.
> Of course, a DB Page Manager would still require explicit folder configuration.
That is why I am leaning more towards a page-based system.

> 
> If we have folders and pages can't JCMS support be added then "on top" later?
+1.  JCMS may over complicate things in in the beginning.

> 
> > 
> >> One important issue I would have with it though is that it wouldn't 
> >> allow me to render page fragments/portlets in a menu, not external links.
> >> Likewise, I don't see how a TabbedPane could be rendered for the 
> >> current page using the folder
> >> concept.
> > 
> > 
> > I believe the tabbed pane could automatically pick up the folder's 
> > children nodes as its menu options
> > This is a valid use case, but not the only use case
> I meant in this case a TabbedPane displaying fragments defined *within* a page.
I don't I like idea of navigating "within" a page.  A page should be
your final stop, all fragments being rendered at once.

> You won't have a folder then.
> 
> > What about external links, links to other pages...
> > Or perhaps the folder is how someone defines a menu
What about having a special link file that you drop into a folder?  Just
a plain text file with url in it.  You could even go as far as dropping
velocity template into a folder to support more complicated menu items
and such.

> > 
> >>
> >> The other proposal from David Taylor was defining new psml menu and 
> >> menu-item elements which could reference pages, (external) fragments 
> >> and external links (see 3).
> >> I understand Scott didn't like adding additional data structures into 
> >> the mix (see 4), but I for one would prefer this
> >> above the folder/page -> menu concept. AFAIK its way more flexible and 
> >> probably much easier to understand for a user.


> >> And, it isn't that different from the J1 implementation. Recreating 
> >> the current J1 features for J2 will be relatively easier to do I think.
> >>
> >> Note: I know the folder concept is not *just* about menus. I'm not 
> >> opposed to folders in anyway. I just think its
> >> to restricted for menu rendering.
> >>
> > Can we support both, or is that too confusing to the end user?
> > See 4 for the menu xml syntax:
> > 
> > <menu type='folder' url='/myfolder'/>
> > 
> > which would generate a menu based on a folder
> +1. I'm all for folder support on this. But not to be restricted by it.

This was exactly my reasoning for using menu/folder concept.  I think a
good compromise would be this: standard navigation would be built using
the folder concept.  However, we can introduce an optional "menu"
fragment that would be sourced from a .menu file that contained a
standardized xml format (like format proposed above).

Next we introduce the idea of a navigation renderer that would consume
and render either .menu files OR folder/page structures.  You could have
multiple navigation renders on a final portal page.  Renders could also
be limited on the number of levels they should render.  For example, you
could have tabbed renderer at the top of a page, and tell it to only
render the first 2 nested levels of folders.  Then on the left hand side
of the page, we have tree-like menu render that renders from level 3 on
down.

The navigation renderer gives us a very fine grained control over how we
render our navigation and separates the model (.menu or folders) from
the view. 

Custom ordering of navigation could be done by storing item order in
user preferences.

> 
> > 
> >> I'd like some comments and if already possible a vote which way we 
> >> should go about menu rendering.
> >> I know I'll something soon ;-)
> > 
> > 
> > Yes well lets try to get some consensus on design first
> :-)
> I don't want to push anything here. Consensus must be reached of course.
> I just think its an important structural issue which already has been discussed a few
> times before. After a certain time, its better to decide instead of keep the issue
> dangling ...
> 
> 
> 
> ---------------------------------------------------------------------
> 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