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} Proposal for Layout, pages & Decorator handling in J2
Date Fri, 21 May 2004 17:22:36 GMT

On May 21, 2004, at 5:08 AM, Raphaël Luta wrote:

> Le 20 mai 04, à 19:14, David Sean Taylor a écrit :
>>>> 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 ?
>>>
>> Think of a folder. It has a collection of pages immediately beneath 
>> it. Sub pages are all direct descendants of a folder.
>>
>
> 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 pages
>   is certainly not injective (several menu items may point to the same 
> page) nor surjective (some pages may not be
>   referenced at all).
Yes, and pages can be deleted and the menu references will be left 
hanging
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 ?
>   In, J2 PSML Pages are *always* user-independant.
>
Well they also worked with groups and roles, but yes, a jslink was user 
dependent
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
david@bluesunrise.com
[office]   +01 707 773-4646
[mobile] +01 707 529 9194



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