portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] Menu implementation
Date Tue, 15 Jun 2004 17:20:17 GMT

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

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

> 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 believe the page within a page concept can be easily supported via 
the profiler's portal URI space, a CMS-like tree

>
> - 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 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
What about external links, links to other pages...
Or perhaps the folder is how someone defines a menu

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

> 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


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