portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaël Luta <raph...@apache.org>
Subject Re: [J2} Proposal for Layout, pages & Decorator handling in J2
Date Fri, 21 May 2004 12:08:03 GMT
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 ?

>>> <snip>
>>> This leads to the last piece missing: tabs and menus like in J1.
>>> Like in J1, tabs and layout menus should be supported with the 
>>> current J2 fragment model.
>>> Like with J1 controllers and controls, menus will be a combination 
>>> of page and portlet decorators.
>>> I will check in a document on PSML covering these issues.
>>> Once the draft is checked, please feel free to change it to meet the 
>>> design we create here
>> I'm not sure this is optimal actually. Sure the J1 system has proved 
>> quite versatile and flexible
>> in handling a variety of requirement but OTOH it's somewhat 
>> non-intuitive for new users who
>> apparently expect some place to configure the menu/tabs somewhere.
> Have you ever tried to explain how Jetspeed menus and tabs function 
> and their relationship to PSML in front of a group of people?
> "Somewhat non-intuitive" is an understatement ;-)

LOL :) Yes I know how it feels... but then I often get these kind of 
confused looks from people when I try to explain
how everything works. ;P

>> 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 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).
- 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 ?
   If you chose "smart", how will this link be constructed to provide 
hints for the profiler ?
   In, J2 PSML Pages are *always* user-independant.

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" :)

>>>> <snip>
>>> The location of a page is handled by the profiler.
>>> The profiler page location strategy is not fixed.
>>> Create a rule to use the query parameter named 'page' to find the 
>>> page.
>>> I also need to document the new profiler
>>> The profiler will need a portlet to aid the administrator in 
>>> defining profiling rules
>>> The profiler in J2 is completely parameterized
>>> Nothing is hard-coded as in J1
>>> This is just the default implementation, locating pages.
>>> A more complex profiler could dynamically create pages and layout 
>>> based on runtime information
>> You can actually do that in J1 if you are willing to re-implent the 
>> profiler service.
> Go on then, start coding ... ;-)

I wrote 2 implementations of it for some internal projects 2 year ago 
(esp. because I needed a client IP driven user
profiling). Very easy when you don't try to provide a "generic" 
solution like the default profiler does.

Raphaël Luta - raphael@apache.org
Apache Jetspeed - Enterprise Portal in Java

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message