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 ?
Have you ever tried to explain how Jetspeed menus and tabs function and their relationship to PSML in front of a group of people?<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.
"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 - [EMAIL PROTECTED] Apache Jetspeed - Enterprise Portal in Java http://portals.apache.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
