The following comment has been added to this issue:
Author: David Sean Taylor
Created: Fri, 4 Jun 2004 11:51 AM
Body:
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
> basis.
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....
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-69?page=comments#action_35910
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-69
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JS2-69
Summary: Finallizing Portal Navigation using the Profiler
Type: New Feature
Status: Unassigned
Priority: Critical
Project: Jetspeed 2
Components:
Profiling/Portal Navigation
Versions:
2.0-dev/cvs
2.0-a1
Assignee:
Reporter: Scott T Weaver
Created: Fri, 4 Jun 2004 8:56 AM
Updated: Fri, 4 Jun 2004 11:51 AM
Description:
We still haven't settled on how we are going to generate navigations in J2. I have
some modifications to the Profiler and to the theme logic which may give us some
direction. I am bringing this up as I have been privellage to quite a few vendor
portal demos lately allowing me to see both the good and the bad of multiple
implementations.
- 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.
- Folder items would be ordered the following way: first by assigned index then by
alphabetical order.
- 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 basis.
- 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.
- 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.
- DO NOT introduce the idea of controls and controllers. It has been stated before
that these easily confuse people and I agree 100%. We 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.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
