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 see pages as existing in a bug bucket of pages.
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).
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 moreIm -1 on nested pages, and +1 on nested fragments (references), which does not need to be implemented in the first solution
simple model implemented first before going that road.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
