On May 21, 2004, at 5:08 AM, Rapha�l Luta wrote:
Le 20 mai 04, � 19:14, David Sean Taylor a �crit :Think of a folder. It has a collection of pages immediately beneath it. Sub pages are all direct descendants of a folder.The phase2-schema.xml has support for SUB_PAGES.
The database PSML schema design (not completely implemented in the component) also supports the concept of FRAGMENT_REFS
Like J1 references, a fragment reference references fragments outside of the current page.
Unlike J1 references, these fragments are not associated with a page but can stand alone.
I don't really understand what SUB_PAGES are for. Can you elaborate ?
What's the benefit of this structure compared to simply having a menu descriptor ?
Its orthogonal to menu structures.
Im working on a proposal/design doc for CMS support built into Jetspeed.
The profiler currently supports PSML pages.
Im proposing supporting a typical file system-like hierarchy (CMS) of folders, sub-folders, documents.
PSML is simply one kind of document.
This means that we can uniformly address all documents, PSML included, in a common namespace.
With CMS integration, PSML could also be versioned.
Regarding menus in PSML, lets begin a discussion here. Im thinking of a separate section in the PSML:
<menus>
<!-- traditional J1 type menu built off a fragment collection --> <menu name='TabOuterMenu' fragment='OuterPortlets'/>
<!-- mixed menu, external links, pages, page/fragment, local fragment -->
<menu name='Example'>
<!-- link to another page -->
<menu-item name='AnotherPage' page='/employees/benefits/401K' />
<!-- link to another page,fragment -->
<menu-item name='AnotherFrag' page='/employee/benefits/401K,CalculatorPortlet'/>
<!-- link to an 'outside' url --> <menu-item name='Outside' url='http://www.apache.org'/>
</menus>
<fragments name='OuterPortlets' >
....
I think it may be worthwhile to explore the benefits of actually having explicit "menu descriptors" stored in
J2. I need to think more about it...
I need to think about it too.
I'd like to also define menu options that link to other places in the portal, and even locations outside of the portal
+1 but the relationship between profiler and such a menu based portal structure is nn-trivial.
Things to consider:
- if we keep a request pipleine like
request -> capability -> profile -> page
How do we know where this page is in the menu ?
The link still needs to go thru the profiler somehow or a similar process.
In J1 you see that JetspeedLink creates links with media type built in, for example
The mapping function between the menu and the available pagesYes, and pages can be deleted and the menu references will be left hanging
is certainly not injective (several menu items may point to the same page) nor surjective (some pages may not be
referenced at all).
However if the PSML is normalized as in the J2 DB PSML DDL, we can put in referential constraints
- if you have loaded a page with a "menu" component displayed on it and you click on link provided by this menu, is this
link considered "dumb", ie the portal will provide the request Page ID without any profiling or "smart" where you allow the
profiler to modify the target based on its logic ?
I think it should be smart
In J1 it was made smart at the time the link was generated (Im speaking of JetspeedLink, which is also the basis for J1 forwards)
I
If you chose "smart", how will this link be constructed to provide hints for the profiler ?Well they also worked with groups and roles, but yes, a jslink was user dependent
In, J2 PSML Pages are *always* user-independant.
I have to give that some thought...
These questions are just scratching the surface of the implications of using a dual profiler + menu driven portal.
The challenge is not to make such a setup "non-intuitive" :)
Well I think menus are intuitive, thats a starting point Now we have to make the links both smart and intuitive...
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
