You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by ji...@apache.org on 2004/06/04 17:57:53 UTC
[jira] Created: (JS2-69) Finallizing Portal Navigation using the Profiler
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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 8:56 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
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by je...@jakarta.apache.org.
The following comment has been added to this issue:
Author: Scott T Weaver
Created: Thu, 2 Sep 2004 9:37 AM
Body:
Current status based on http://www.mail-archive.com/jetspeed-dev@jakarta.apache.org/msg14579.html
Here is what I have done so far:
- Created a CMSish node/document handling api to easily allow us to support documents other than .psml. This will also make transitioning to a CMS backed repository, like JCMS much easier.
- Refactored CastorXMLPageManager to just delegated to the new CMSish api. We can probably rename it since the new CMSish api can easily support RDBMS or whatever.
- Added support for folder metadata which current supports the current functionallity: node ordering, localization and acl assignment.
- Pages (.psml) now fully support localized metadata
- Added document handler support for .link docuemnts that just link out to an external URL.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-69?page=comments#action_39524
---------------------------------------------------------------------
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: Thu, 2 Sep 2004 9:37 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
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by 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
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Randy Watler (JIRA)" <je...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59481 ]
Randy Watler commented on JS2-69:
---------------------------------
>From "Ate Douma" <at...@douma.nu>
Subject Re: Declarative or Modal Page Layout Navigation?
Date Sun, February 20, 2005 1:57 pm
To "Jetspeed Developers List" <je...@jakarta.apache.org>
Randy Watler wrote:
> Team,
>
> David and I have been discussing potential options to the current
> profiler/page-manager generated page layout navigations. While what we
> have seems to be fairly powerful and flexible, it also seems to be too
> complex and/or scalable for use by many users. It often raises questions
> on the lists and certainly does not seem self documenting!
Fully agreed!
>
> We have discussed implementing a declarative navigation definition,
> (i.e. J1 menus), that could be specified globally or at the folder
> level. We have also pondered some modal configuration settings/hints to
> the existing solution that correspond to different navigational styles,
> (i.e. relative forward/back navigation as we currently have, constant
> navigation elements that reflect the physical folder structures, logical
> view specifications like document sets, etc.). Obviously, changes to
> support these different modes would also involve modifications to the
> various velocity layout templates. Related efforts might include support
> for javascript pull down menus or other portal navigation interfaces.
+1 ;-) One of my own outstanding requirements I haven't found time yet to
find a solution for.
We've been here before and several solutions have been suggested in the
past (including one of my own). Lets try to get this right once and for
all!
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
>
> 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.
--
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
[jira] Resolved: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Randy Watler (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=all ]
Randy Watler resolved JS2-69:
-----------------------------
Resolution: Fixed
All important aspects of this issue have been resolved with the implementation of the portal-site component.
See J2 /design-docs/src/portal-site for updated documentation.
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-a1, 2.0-dev/cvs, 2.0-M1, 2.0-M2, 2.0-M3
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
> Fix For: 2.0-M4, 2.0-FINAL
> Attachments: portal-navigations-component.sxw
>
> 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.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Scott T Weaver
Created: Fri, 4 Jun 2004 12:26 PM
Body:
> 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.
I like that idea, makes sense and it standardized, as long it is just as easy to comprehend as folders that contain folders and/or pages. And only then if the same Page can be inside multiple folders at once, like a sim link except that a Page's hard reference does not live in any folder. To simplify, you ALWAYS access a page as a reference.
> 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.
> Perhaps a unique index would also be a valid page identification
> method.
That's fine with folders being nodes. But if we use them as the basis for building navigation, optional ordering attributes are a must. -1 on unique index as to folders may end up with the same ordering number in which case alphabetical order would sort it out.
> 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.
A Theme is really just the decoration that surrounds the layout. I like theme because it sets the overall look and feel of the page and it is a very popular buzz word and it seems that most vendor portals are using the term "theme" to describe what we call a layout decorator. I would like to keep with present day vernacular were we can.
> 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 am -1 on adding another data structure to the mix, that just complicates things. IMOHO, menu = control from J1. I think we can kill 2 birds with one stone by relying on the naturally hierarchical nature of using folders (nodes) which contain pages and other folders (nodes). We just need to allow for manual ordering of those elements by assigning ordering, which is only relevant during rendering and would have nothing to do with actual folder/page structure itself. As I said before, let the Profiler figure out how to aggregate all the folders that user has access to based on an ACL that is attached to that folder/page or add additonal profiling rules that limit it even further, but the ACL based profiling rule would be the broadest as you can't have access anything greater than the security you have been assigned. So basically, the ACL profiling rule should be the default.
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-69?page=comments#action_35913
---------------------------------------------------------------------
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 12:26 PM
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
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Scott T Weaver (JIRA)" <je...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59509 ]
Scott T Weaver commented on JS2-69:
-----------------------------------
Everything is sounding great so far! I really like the idea of caching the navigations as I think it would really help performance.
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
>
> 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.
--
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
Re: [jira] Commented: (JS2-69) Finallizing Portal Navigation
usingthe Profiler
Posted by wa...@wispertel.net.
> ... For the Portal Navigation solution(s), I very much would like to see a
> similar strategy be used. Determine a few (at the most) very simple
Navigation styles and
> build that as small,light and fast components. Once that would be in
place, more powerful
> enhanced components can be created for handling the more complex
solutions like the
> ones we have right now...
I understand your aim here and am generally supportive of your ideas. An
equally important requirement is to isolate the logic from the underlying
PSML content implementation, (file system/XML, DB, CMS, etc.).
Still, the biggest question remains: what is that set of minimal solutions
we want to provide? We have three proposed or existing implementations so
far:
- XML based menu definitions,
- regex path set menu definitions, and
- the existing page relative navigation set.
I am guessing that these could be broken into multiple components that
share a common base implementation that facilitates interaction with the
profiler and folder/document representations, (where security is
implemented). I think the the primary reason to break these features into
separate modules/components will be to avoid unnecessary/unused computed
results.
The only wrinkle here is that it might be interesting to use multiple
components simultaneously. For example, top level navigations might use an
XML menu definition and page relative sibling folders and pages could be
used for deeper levels in the site beyond the top few folders.
Another question is whether the various approaches can be unified under
one API for use by the layout templates. I am still pondering this, but on
the surface it seems that it might just add more confusion than it is
worth. If the API becomes too generic, (like simply providing all profiled
pages and folders in one big graph/hierarchy), all of the layout logic
will simply end up moving into the templates... I do not think we want
that, (or do we)?
In the end, we might need to avoid doing ANY navigation computation in
advance and defering it alltogether until the layout templates actually
request a particular navigation elements set. I am not sure how that would
be best implemented as individual components.
Still thinking!
Randy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-69) Finallizing Portal Navigation using
the Profiler
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
> Randy Watler (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59483 ]
>> Randy Watler commented on JS2-69:
>> ---------------------------------
>>
> First let me say that the profiled navigation is very powerful and very
> useful for me. I have several sites running using role-based aggregation
> of navigations, and it works great. On the negative side, it wasn't easy
> to configure. What we need is something very intuitive that can be
> tooled into a UI so that site maps can be created easily. I agree with
> Randy: we need a better abstraction. Perhaps the site map abstraction is
> right.
>
> From my experience and user requirements, I had trouble getting menus
> to match the folder/page tree. I spent hours trying to get the
> algorithms to produce something that I could much more easily and more
> and intuitively generate with a declarative XML menu data structure.
> (yes im bringing this up again.)
>
> > Generally, the goal is to provide some basic information "out of the
> > box", (i.e. w/o the need for document sets or other configuration
> > information), to support typical navigations for small to medium
> > sized portals.
>
> One use case that keeps popping up is a rootless tree.
> I find myself working around the root. If I have a need for for top
> menus as folders, and then submenus as psml, i have to move one
> arbitrary folder down into the root.
>
> > "{/*,/*/,/deep0/*,/deep1/*,/deeper/*/}". Of course, a simple default
> > > like "{/*,/*/*}" would due in many cases. If paths are too limiting,
> > a full XML menu definition might be required... but there have been
> > other votes against such a thing.
>
> not my vote
>
> > Given that the profiler would be used to generate this "site map", it
> > does not seem that any capability to specify multiple menu definitions
>
> Ive already written several applications using the profile per user
> approach along with navigations. I would suggest that dealing with
> backward compatibility is important
>
> My opinion is that trying to build the menu on the fly off of the
> physical layer may not be the best approach. A better abstraction could
> leverage all the work Randy put into profiled-pages and navs. Perhaps
> this abstraction is a site map or a declarative xml menu in the folder
> metadata.
>
I'd like to propose we try to tackle this beast by using more divide and conquer.
In my honest opinion, the current page context aggregation is very powerful, but
also quite difficult to use. In a lot of situations, its full power isn't needed
and can get more in the way than helping out...
I'm currently refactoring the whole deployment functionality and the thing that
is taking the most of my time is the complexity of the current implementation.
The solution I'm following right now is stripping the whole thing to its bare bones
and refactor whats left.
J2 its most prominent architectural aspect is that it is component based down to the core.
Although I've stripped a lot of deployment functionality, I found out that most of it
isn't used (not by J2 itself at least, maybe others have already build upon some features
we don't use yet).
After I have finished the deployment refactoring, I'm willing to build then considered *lost*
functionality back *on top* of the bare bones default deployment components, but only as
optional, configurable enhanced components. Not back into the default/base/core
components. Those I think we should always try to keep simple, slim and bare to the bones.
For the Portal Navigation solution(s), I very much would like to see a similar strategy be
used. Determine a few (at the most) very simple Navigation styles and build that as small,
light and fast components. Once that would be in place, more powerful enhanced
components can be created for handling the more complex solutions like the ones we
have right now...
I'm not actually working on this issue and don't have enough time available yet to get
more involved so don't take my opinion as more than that. I know its way easier to write
about it than doing it ;-) But, with my current experiences with the deployment refactoring
I do think it might actually speed things up a lot...
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [jira] Commented: (JS2-69) Finallizing Portal Navigation using
the Profiler
Posted by David Sean Taylor <da...@bluesunrise.com>.
Randy Watler (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59483 ]
>
> Randy Watler commented on JS2-69:
> ---------------------------------
>
First let me say that the profiled navigation is very powerful and very
useful for me. I have several sites running using role-based aggregation
of navigations, and it works great. On the negative side, it wasn't easy
to configure. What we need is something very intuitive that can be
tooled into a UI so that site maps can be created easily. I agree with
Randy: we need a better abstraction. Perhaps the site map abstraction is
right.
From my experience and user requirements, I had trouble getting menus
to match the folder/page tree. I spent hours trying to get the
algorithms to produce something that I could much more easily and more
and intuitively generate with a declarative XML menu data structure.
(yes im bringing this up again.)
> Generally, the goal is to provide some basic information "out of the
> box", (i.e. w/o the need for document sets or other configuration
> information), to support typical navigations for small to medium
> sized portals.
One use case that keeps popping up is a rootless tree.
I find myself working around the root. If I have a need for for top
menus as folders, and then submenus as psml, i have to move one
arbitrary folder down into the root.
> "{/*,/*/,/deep0/*,/deep1/*,/deeper/*/}". Of course, a simple default
> > like "{/*,/*/*}" would due in many cases. If paths are too limiting,
> a full XML menu definition might be required... but there have been
> other votes against such a thing.
not my vote
> Given that the profiler would be used to generate this "site map", it
> does not seem that any capability to specify multiple menu definitions
Ive already written several applications using the profile per user
approach along with navigations. I would suggest that dealing with
backward compatibility is important
My opinion is that trying to build the menu on the fly off of the
physical layer may not be the best approach. A better abstraction could
leverage all the work Randy put into profiled-pages and navs. Perhaps
this abstraction is a site map or a declarative xml menu in the folder
metadata.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Randy Watler (JIRA)" <je...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59483 ]
Randy Watler commented on JS2-69:
---------------------------------
After reviewing Ate's proposal and comments from 7/3/2004, (http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=15857), and factoring in recent discussions on the topic, it seems that there is the beginning of a consensus around providing a profiled view of folders and pages from the root to a specified depth. This top level "site map" could be used to drive global portal navigations that supplement or replace the existing page relative navigation elements.
Generally, the goal is to provide some basic information "out of the box", (i.e. w/o the need for document sets or other configuration information), to support typical navigations for small to medium sized portals.
Support for profiling is a must, so simply returning a reference to the underlying physical view of the portal content is not acceptable. However, a hierarchical object representation of the "site map" that contains profiled folders and documents is probably required to allow nested menu representations including javascript dhtml pulldown renderings to be constructed easily.
The desired "depth" of the root level "site map" would probably need to be somewhat variable to support ragged pulldown menu trees. Consequently, it seems that some form of a menu definition will be required, minimally some kind of path set specification like: "{/*,/*/,/deep0/*,/deep1/*,/deeper/*/}". Of course, a simple default like "{/*,/*/*}" would due in many cases. If paths are too limiting, a full XML menu definition might be required... but there have been other votes against such a thing.
This "site map" would probably be specified globally, or possibly at the individual folder level. If folder level specification is required, it should support some form of inheritance so that navigations specified in the root or parent folders would serve as the default folder menu definition.
Given that the profiler would be used to generate this "site map", it does not seem that any capability to specify multiple menu definitions per user, group, role, mediatype, etc. would be needed or desirable. Instead, the contents of a single "site map" would be determined by profiler folder aggregation and security filtering. If folder level specification is implemented, the specific folder and menu definition could also be selected by the profiler as a by product of selecting the portal page to be displayed.
Caching of these portal "site maps" can be significantly easier than reusing the existing navigational elements generated today. In fact, if folder level specification is not supported and a single global menu definition is allowed, the resulting "site map" can be generated once and cached per session. This advantage should be carefully considered when making the decision to support folder level specification.
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
>
> 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.
--
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
[jira] Updated: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Randy Watler (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=all ]
Randy Watler updated JS2-69:
----------------------------
Version: 2.0-M1
2.0-M2
2.0-M3
Fix Version: 2.0-M4
2.0-FINAL
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1, 2.0-M1, 2.0-M2, 2.0-M3
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
> Fix For: 2.0-M4, 2.0-FINAL
> Attachments: portal-navigations-component.sxw
>
> 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.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Randy Watler (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=all ]
Randy Watler updated JS2-69:
----------------------------
Attachment: portal-navigations-component.sxw
Initial Design Document For Review/Comment
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
> Attachments: portal-navigations-component.sxw
>
> 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.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Assigned: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Randy Watler (JIRA)" <je...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=history ]
Randy Watler reassigned JS2-69:
-------------------------------
Assign To: Randy Watler
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
>
> 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.
--
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
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Scott T Weaver (JIRA)" <je...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59658 ]
Scott T Weaver commented on JS2-69:
-----------------------------------
Randy Walters reply (pulled from a direct reply email)
I understand your aim here and am generally supportive of your ideas. An
equally important requirement is to isolate the logic from the underlying
PSML content implementation, (file system/XML, DB, CMS, etc.).
Still, the biggest question remains: what is that set of minimal solutions
we want to provide? We have three proposed or existing implementations so
far:
- XML based menu definitions,
- regex path set menu definitions, and
- the existing page relative navigation set.
I am guessing that these could be broken into multiple components that
share a common base implementation that facilitates interaction with the
profiler and folder/document representations, (where security is
implemented). I think the the primary reason to break these features into
separate modules/components will be to avoid unnecessary/unused computed
results.
The only wrinkle here is that it might be interesting to use multiple
components simultaneously. For example, top level navigations might use an
XML menu definition and page relative sibling folders and pages could be
used for deeper levels in the site beyond the top few folders.
Another question is whether the various approaches can be unified under
one API for use by the layout templates. I am still pondering this, but on
the surface it seems that it might just add more confusion than it is
worth. If the API becomes too generic, (like simply providing all profiled
pages and folders in one big graph/hierarchy), all of the layout logic
will simply end up moving into the templates... I do not think we want
that, (or do we)?
In the end, we might need to avoid doing ANY navigation computation in
advance and defering it alltogether until the layout templates actually
request a particular navigation elements set. I am not sure how that would
be best implemented as individual components.
Still thinking!
Randy
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
>
> 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.
--
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
Re: [jira] Commented: (JS2-69) Finallizing Portal Navigation using
the Profiler
Posted by David Sean Taylor <da...@bluesunrise.com>.
Randy Watler (JIRA) wrote:
> [
> http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59846
> ]
>
> Randy Watler commented on JS2-69: ---------------------------------
>
> Team,
>
> After devoting some time to this issue over the week I think I have
> come up with the heart of a proposal. I plan on commiting it to an
> official design document in all of its glory soon, but I would like
> some feedback first.
>
Randy,
Im going to try to summarize your proposal so that I can better
understand it. Lets try to stay out of too many implementation issues
for now...
* There will be a new session context object: Site
* The profiled page context object will no longer be used directly
Instead Site should be used in all navigation templates
If this is correct, then with your upcoming official document, could I
request to see a public API (interfaces) for the new Site interface and
high level examples for several use cases
> 3. Basic utilities will be implemented by the site session context
> object that mimic the existing PageManager/Profiler features. These
> will minimally include: getPage(), getFolder(), getSiblingFolders(),
> getSiblingPages(), and getRootLinks(). The new getRootFolder(),
> getRootPages(), and getRootFolders() access will also implemented to
> facilitate ad-hoc access to the root of the profiled site.
>
Is this for backward compatibility?
I have existing systems usuing the page context 'api'...
> 4. Document sets will be deprecated and replaced with named menu
> definitions that will appear in the folder.metadata files. In the
+1
In you design doc, could you provide examples of menu definitions
> 5. The implementation of the functionality behind the site session
> context object and its proxy hierarchies will be encapsulated in a
> separate component I am referring to as the PortalNavigations
> component. I am also considering the implementation of another
> compatible component that simply returns underlying Folders, Pages,
> and other documents from the PageManager without employing the
> Profiler or Security; this would also eliminate the need for proxies
> and delegation.
There is a Site session object used internally
Then a PortletNavigations component...
Perhaps some UML (sorry XPers) or even circles and lines would help
about now (components, pipeline context interfaces, interfaces provided
to template developers). I need to start at a higher, design level
before getting into all of the implementation details
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Randy Watler (JIRA)" <je...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59846 ]
Randy Watler commented on JS2-69:
---------------------------------
Team,
After devoting some time to this issue over the week I think I have come up with the heart of a proposal. I plan on commiting it to an official design document in all of its glory soon, but I would like some feedback first.
Here is the general scheme:
1. An inital request comes in for a authenticated user immediately after login on some request url, (usually the portal root). Since this is the first request in a new session for the end user, the PageManager, Profiler, and new PortalNavigations component initializes a new context object that is attached to the session. This object will hold all cached profiled site information for the session to maximize reuse/scaling and hold sufficient state information about the user, pages, and active profiling rules to allow it to compute profiled site portal navigations dynamically later in the execution of the request pipeline.
2. The "site" session context object is initialized/reset with only these elements when the ProfilerValve is invoked in the pipeline: the root folder, the current page, and a creation timestamp. All Folder, Page, and other document instances managed within the site session context object will be proxies that are arranged into a standard hirarchical site definition with the aid of the PageManager and Profiler. Unlike the current implementation, all elements managed by the site session context can be navigated to locate relative profiled site content, (i.e. getParent(), getSiblingFolders(), getFolders(), etc. will reflect the profiled site). These proxies will delegate all access and operations to the underlying objects managed by the PageManager, except those that maintain the proxy hierarchy. As mentioned, the initial site session context object will be sparsely populated. As the end user navigates through the portal and the Page Layout Templates are constructed, the site session context object will cache more of the profiled site definition by constructing the proxy hierarchy dynamically. The cached proxy hierarchy will be cleared when the session is destroyed or the PageManager cache is cleared due to a change in the physical PSML content.
3. Basic utilities will be implemented by the site session context object that mimic the existing PageManager/Profiler features. These will minimally include: getPage(), getFolder(), getSiblingFolders(), getSiblingPages(), and getRootLinks(). The new getRootFolder(), getRootPages(), and getRootFolders() access will also implemented to facilitate ad-hoc access to the root of the profiled site.
4. Document sets will be deprecated and replaced with named menu definitions that will appear in the folder.metadata files. In the broadest terms, these new folder based menu definitions will be a super set of the existing document set features. In addition to the ability to define and profile multiple menu definitions using alternate profiling rules and regular expression path sets, new capabilities based on explicit XML menu tags to define ragged nested menus inline will be implemented. Also, common menu design patterns/idioms can be easily specified using the declarative XML menu tags, (e.g. it would be trivial to define a simple XML definition to specify a menu tree composed of all root level folders and their pages). Individually named menu definitions will be inherited, (in a strictly non-aggregating style), down the profiled PSML hierarchy as one would expect so that they can be overriden in lower levels in the site. When accessed by the Page Layout Templates, the site session context object will construct and cache each named menu definition using another hierarchy of proxied Folder, Page and other document instances. This proxy hierarchy can be easily navigated by the Page Layout Templates to generate many simple or cascading Portal Navigation styles.
5. The implementation of the functionality behind the site session context object and its proxy hierarchies will be encapsulated in a separate component I am referring to as the PortalNavigations component. I am also considering the implementation of another compatible component that simply returns underlying Folders, Pages, and other documents from the PageManager without employing the Profiler or Security; this would also eliminate the need for proxies and delegation. Given the flexibilty of the intended APIs outlined above, I am not sure there is a need to micro componentize the full function PortalNavigations functionality. By only computing exactly what a Page Layout Template requests and employing session based caching, it is not clear that any performance advantage would be realized by further decomposition. However, I am still considering the implementation of individual menu definition idioms as components.
6. At the moment, I am assuming that different Page Layout Templates would be developed for the different HTML/javascript menu presentation styles. However, it would be relatively trivial thing to provide a menu presentation style attribute to the menu definition XML tags if we felt that having one template support multiple presentation styles was ideal.
7. I am also initially requiring that default menu definitions would be placed in root folder.metadata files. This will allow them to be profiled, and thus overriden, as is done with all PSML content. However, it might be desirable to allow menu definitions to be specified in the PortalNavigations Spring configuration or by other valves in the request pipeline. I am not intending to support these or other alternatives in this implementation unless someone can come up with a compelling use case.
Whew! Ok gentlemen, pick up you stones and have at the straw man!
Randy
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
>
> 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.
--
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
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
Posted by "Scott T Weaver (JIRA)" <je...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59657 ]
Scott T Weaver commented on JS2-69:
-----------------------------------
Ate Douma's comments (pulled from a direct response email)
I'd like to propose we try to tackle this beast by using more divide and conquer.
In my honest opinion, the current page context aggregation is very powerful, but
also quite difficult to use. In a lot of situations, its full power isn't needed
and can get more in the way than helping out...
I'm currently refactoring the whole deployment functionality and the thing that
is taking the most of my time is the complexity of the current implementation.
The solution I'm following right now is stripping the whole thing to its bare bones
and refactor whats left.
J2 its most prominent architectural aspect is that it is component based down to the core.
Although I've stripped a lot of deployment functionality, I found out that most of it
isn't used (not by J2 itself at least, maybe others have already build upon some features
we don't use yet).
After I have finished the deployment refactoring, I'm willing to build then considered *lost*
functionality back *on top* of the bare bones default deployment components, but only as
optional, configurable enhanced components. Not back into the default/base/core
components. Those I think we should always try to keep simple, slim and bare to the bones.
For the Portal Navigation solution(s), I very much would like to see a similar strategy be
used. Determine a few (at the most) very simple Navigation styles and build that as small,
light and fast components. Once that would be in place, more powerful enhanced
components can be created for handling the more complex solutions like the ones we
have right now...
I'm not actually working on this issue and don't have enough time available yet to get
more involved so don't take my opinion as more than that. I know its way easier to write
about it than doing it ;-) But, with my current experiences with the deployment refactoring
I do think it might actually speed things up a lot...
Ate
> Finallizing Portal Navigation using the Profiler
> ------------------------------------------------
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
>
> 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.
--
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