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
Nested fragments, but not as references, are already used by the layout portlets!
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.
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.
- 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? So no definition needed in the psml.
Of course, a DB Page Manager would still require explicit folder configuration.
If we have folders and pages can't JCMS support be added then "on top" later?
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.
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
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
