I have an implementation in place of the profiler that is not documented.
Let me try to explain it...
J2 looks at the URL path, and considers everything after "jetspeed/portal" to be the path to a PSML page up unto it finds a "navigational state parameter". Navigational state manages state changes with the Portlet API: window state and portlet mode changes. They are the parameters that you see starting with "_".
If you look at the Struts page, or the PAM page, you will see that the path to the PSML page (page) is always before the navigational state parameters.
The current design is to specify the path to a folder or page in the URL, before nav state:
/jetspeed/portal/folder-1/folder-2/target-page/_nav-state params ...
This means that /folder-1/folder-2/target-page is the path to the identified PSML
> I would say we replace the getDesktop() with getFolders(). There is really no need for a
> "root" item or Folder per se since we will be leaving this job to the current set of
> profilling rules that have been assigned to the Profiler.
> Folders will contain any number of pages and/or folders.
Yes, we seem to have lost the desktop idea. lets drop it.
What do you think about storing pages and folders in a CMS?
This would allow versioning of PSML resources.
Im currently reviewing JSR170 (Content Repository) to get a better idea of how JCMS could be standardized.
> Folder items would be ordered the following way: first by assigned index then by alphabetical order.
I see folders being order as CMS nodes, in a tree navigation like the example above.
Folders and pages should all be accessible across a normalized portal wide URL where "/" is the root folder, like an operating system, or like a site map.
Perhaps a unique index would also be a valid page identification method.
> Remove defaultPage logic from Folder, the focused Folder item would be set in this
>fashion: set the focus to the last selected child in that Folder then by Folder Item
> ordering algothrim defined above.
>It should be the Profiler's responsibility to preserve a user's active item on a per Folder
Yes, we can drop default page.
> A Folder would still posses the defaultTheme capabillity but with the added abillity to
> enforce the defaultTheme on its childern and its childrens' children by overriding the
> theme settings for those items with its own.
OK, this is where we REALLY need specification documents before coding.
Roger has written and checked in a document describing the basic model for Jetspeed markup components. There we have agreed to define: decorators and layouts.
There is currently no definition there of a theme.
I suggest we work together on clearly defining these concepts, as its still unclear.
> - Rendering the contents of the Profiler.getFolders() would be left entirely up to the
> theme (currently called the layout decorator). Example: a theme could render the first 2 > levels as tabs and the rest as a hierarchical menu to the left of the layout area.
What about having menu elements in PSML?
I started this discussion on jetspeed-dev a while back, but had no response.
A menu could link to either the current page, or outside the page.
Could you please review that and comment on it?
need to keep things simple.
> I think the first profiling/navgation implementation would be assigning n number of
> roles to a top-level folder. Then allow the Profiler to aggregate what Folders a user has
> access to by comparing the roles that user is assigned to the ones required the Folders
> required roles (ACL?) I think this approach is already somewhat in place but it just needs > some final implementation details.
Im sorry but I don't follow that, why its the job of the profiler to assign roles..
I thought that would be a job of the security component, to create security constraints and apply them to resources such as portlet pages or portlet windows.
Perhaps a folder could have a menu associated with it....