Jetspeed 2
  1. Jetspeed 2
  2. JS2-69

Finallizing Portal Navigation using the Profiler

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0-dev/cvs, 2.0-a1, 2.0-M1, 2.0-M2, 2.0-M3
    • Fix Version/s: 2.0-M4, 2.0-FINAL
    • Labels:
      None

      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.

        Activity

        Hide
        Randy Watler added a comment -

        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.

        Show
        Randy Watler added a comment - 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.
        Hide
        Randy Watler added a comment -

        Initial Design Document For Review/Comment

        Show
        Randy Watler added a comment - Initial Design Document For Review/Comment
        Hide
        Randy Watler added a comment -

        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

        Show
        Randy Watler added a comment - 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
        Hide
        Scott T Weaver added a comment -

        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

        Show
        Scott T Weaver added a comment - 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
        Hide
        Scott T Weaver added a comment -

        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

        Show
        Scott T Weaver added a comment - 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
        Hide
        Scott T Weaver added a comment -

        Everything is sounding great so far! I really like the idea of caching the navigations as I think it would really help performance.

        Show
        Scott T Weaver added a comment - Everything is sounding great so far! I really like the idea of caching the navigations as I think it would really help performance.
        Hide
        Randy Watler added a comment -

        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.

        Show
        Randy Watler added a comment - 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.
        Hide
        Randy Watler added a comment -

        From "Ate Douma" <ate@douma.nu>
        Subject Re: Declarative or Modal Page Layout Navigation?
        Date Sun, February 20, 2005 1:57 pm
        To "Jetspeed Developers List" <jetspeed-dev@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!

        Show
        Randy Watler added a comment - From "Ate Douma" <ate@douma.nu> Subject Re: Declarative or Modal Page Layout Navigation? Date Sun, February 20, 2005 1:57 pm To "Jetspeed Developers List" <jetspeed-dev@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!
        Hide
        Scott T Weaver added a comment -

        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.
        Show
        Scott T Weaver added a comment - 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.
        Hide
        Scott T Weaver added a comment -

        > 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.

        Show
        Scott T Weaver added a comment - > 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.
        Hide
        David Sean Taylor added a comment -

        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....

        Show
        David Sean Taylor added a comment - 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....

          People

          • Assignee:
            Randy Watler
            Reporter:
            Scott T Weaver
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development