Feature Discussions

[toku]

Dear community,

actually, the creation of a hierarchically nested "subnavi" configurations in FirstSpirit sitestore lead to wrong constructed HLP-BP portal links. The standard FirstSpirit portal module "fs-portal.fsm" is responsible for creating these links.

When having a detailed look in class "de.espirit.firstspirit.opt.portal.PortalUtils", a recursion method named "getEntryPoint()" is implemented. There, the link generation error occurs.

The recursion iterates upwards to the root node of the FirstSpirit sitestore structure and then downwards to the first node of type "subnavi". Here the error appears, because the underlying node of type "subnavi" is not reachable by this recursion.

A nested sitestore "subnavi"-configuration could be seen enclosed:

• Change request

- allow creating proper portal links by "fs-portal.fsm" FirstSpirit module when having configured a nested "subnavi" structure

- fix the above mentioned recursion method to allow retrieving nested "subnavi" nodes for the link generation process

[essmann]

In order to complete this feature request, the follwing question has to be answered:

How shall we handle intra-subnavigation portal links?

Definition: Intra-subnavigation links are links that have source and destination node inside the subnavigation.

Today, with not nested subnavigations, the SAP EP poral integration redirects intra-subnavigation links to the navigation node inside the subnavigation and not to the original navigation node in the toplevel navigation. For this purpose FirstSpirit attaches a parameter to intra-subnavigation portal links.

In a nested subnavigation FirstSpirit cannot decide the navigation context of the navigation, because the navigation lies inside of two navigation contexts.

Thus, we need to specify how the intra-subnavigation links should work. Any Suggestions?

[toku]

Hello,

these kind of links ( intra_subnavigation-links ) should handled like normal links and links which are still in place for the not nested my-areas. If we have now a subnavi/my-Area-range the links are working normal within this subnavi-Area and although outside.

Regards

[king]

Dear Mr Eßmann,

concrete, shown in an example:

https://xxx.xxxxx.xxx/FIRSTspiritWeb/wcms/wcms_ds/de/bosch_globalnet/bgn/02_organization/automotive_...&subEntryID=wcms_ds_DS&browserMapping=ie6&themeName=customer/insideTheme

Via the Request-Parameter "subEntryID" the HLP-BP matches the so-called configured "my-area" (=Intra-SubNavigation context). A "my-area" is a subset of a project navigation that has been setup based on "xmlfactory=subnavi" within the "fs-portal.fsm". In this case, the value "wcms_ds_DS" points to the "DS" my-area.

If we would have nested my-areas respectively Intra-SubNavigation contexts, we would have different values for the above request parameter "subEntryID". These values are unique for different sub navigation contexts. So, where is the problem?

[essmann]

FirstSpirit decides the subEntryID for a link embedded in a page at generation time by the according structure variable.

Please consider the following scenario:

sitestore_root

   \_entrypoint

           \_subnavi_x

                    \subnavi_y (nested)

                           \_page_a

                            |_page_b

                            |...

                    |_page_c

                    |_...

            |_...

    |...

• page_b links to page_a
• page_c links to page_a
• subnavi_x is assigned to portal's navigation node1
• subnavi_y is assigned to portal's navigation node2

When following the link from page_c to page_a in the navigation context of portal's navigation node1 the navigation context would jump to the navigation context of navigation node_2, because the subEntryID is set this way.

If you decide to chose the subEntryID to be the outer sub-navigation, the link from page_b to page_a in navigation context of navigation node_2 would lead to a navigation context switch to navigation node_1.

Please, recognize that the subEntryID is not dynamic.

Thus, one has at least to decide which navigation context should be chosen, which may be wrong depending of your navigation context.

Best Regards,

Bernd Eßmann

[king]

Okay - problem is understood!

Feature request conditions:

The feature request - when realized - should behave in the following manner:

- when navigating in ONE my-area within the portal and following links that are pointing to pages, that are even available in a nested my-area, the sub-entry navigation point should NOT switch. Example, referring to the one above:

• page_c links to page_a should NOT lead to a navigation context switch from subnavi_x (node1) to subnavi_y (node2)

- following links in inner/nested my-area pages whose targets point to pages that are located within the same nested my-area location, no navigation context switch should occur. Example, referring to the one above:

• page_b links to page_a should NOT lead to a navigation context switch from subnavi_y (node2) to subnavi_x (node1)

Prerequisites to solve the problem (when possible):

- the HLP-BP has to be informed about the selected my-area, when a user clicks it (e.g. an additional request parameter or additional post information). Maybe, even the portal knows that information aleady, but HLP-BP just has to use it!

- how to decide which page-internal link targets are pointing to the same selected sub-entry navigation context and which one not? Well, the "fs-portal.fsm" FirstSpirit module has to be adapted. Generated portal links, that point to targets within sub-entries have to add that information to the link, so the HLP-BP is able to evaluate it later at runtime.