[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler

[ji...@apache.org]

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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org