2

这个问题与：

我的用例是这样的：

我有多个应用程序应该链接到其他应用程序（深度）。由于交叉导航的文档提到避免深度链接，我决定使用启动参数。

例如：

应用程序 A 在一个项目的详细视图中有一些项目的列表 有对另一个应用程序 B 的引用，其中包含一些其他详细信息。假设 A 显示文章详细信息，B 显示文章制作者的一些详细信息。

应用程序 A 现在将使用如下导航：

sap.ushell.Container.getService("CrossApplicationNavigation").hrefForExternal({
  target : { semanticObject : "ApplicationB", action : "display" },
  params : { "someID" : "102343333"}
})

现在在应用程序 BI 中，在 init 方法末尾的 Component.js 中使用这样的代码。

var oRouter = that.getRouter().initialize();
var oComponentData = this.getComponentData();
if (oComponentData.startupParameters) {
    oRouter.navTo("SomeView", {
        someId : oComponentData.startupParameters.someID[0],
    }, false);
}

第一个问题：这是处理启动参数的正确位置吗？

第二个问题：如果我使用导航启动参数仍然会在代码中，我宁愿删除它，但如何？

更新

在目标应用程序 (B) 中，它将导致以下 URL：

https://server/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html?sap-client=100&sap-language=EN#SemObject-display?someID=102343333&/SomeView(102343333)/

无论如何，我希望有这样的东西：

https://server/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html?sap-client=100&sap-language=EN#SemObject-display?/SomeView(102343333)/
4

3 回答 3

3

参数必须检索为

var oComponentData = this.getComponentData();
if (oComponentData.startupParameters) {
    oRouter.navTo("SomeView", {
        someId : oComponentData.startupParameters.someID[0],
    }, false);

当你写。在 Fiori 应用程序中，注入到构造函数的 Component 数据中的启动参数可能已被重命名，通过进一步的默认值等进行丰富。因此，它们可能与在 url 中观察到的参数不同。建议应用程序不要尝试直接检查 URL。

如果提供了一组非常长的 url 参数，则会观察到 FLP 将其中一些参数替换为 sap-intent-param=AS123424（“压缩 URL”）以解决某些平台和书签中的 url 长度限制，在getComponentData().startupParameters 将接收全套参数）。

至于第二个问题。不，目前没有办法“清理” URL 并避免内部应用程序路由之间的冗余。

SemObject-display?someID=102343333&/SomeView(102343333)/ 导航后可能看起来像 SemObject-display?someID=102343333&/SomeView(102343999)/

应用程序以 102343333 启动，但随后用户在应用程序内导航到另一个项目 (102343999)。

has (SemObject-display?someID102343333) 的“Shell-part”的任何更改都将导致具有不同启动参数的跨应用程序导航（重新实例化您的组件）。

（在某些情况下，流程中需要这样做，例如，通过链接从 OrgUnit 情况说明书到父 OrgUnit 情况说明书的交叉导航）。

SAP 内部有融合应用程序内部路由和意图参数的想法，但没有实施，因为它主要是 url 美学。

注意：为了支持boomarking，在组件实例化过程中必须同时尊重启动参数和内部应用程序路由，假设用户在

SemObject-display?someID=102343333&/SomeView(102343999)/（当他在看 9999（！）时）。

重新实例化应用程序时，内部应用程序路由的优先级应高于启动参数。

所以将代码修改为：

var oComponentData = this.getComponentData();
if (oComponentData.startupParameters) {
    if (sap.ui.core.getHashChanger().getHash()=== "") {
         // if no inner app route present, navigate 
         oRouter.navTo("SomeView", {
               someId : oComponentData.startupParameters.someID[0],
         }, false);
    }

}

https://sapui5.netweaver.ondemand.com/#docs/api/symbols/sap.ushell.services.CrossApplicationNavigation.html

面向开发人员的 SAP Fiori Launchpad，导航概念 http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/907ae317-cb47-3210-9bba-e1b5e70e5c79?QuickLink=index&overridelayout=真实&59575491523067

于 2016-07-28T13:06:07.543 回答
2

我在从 Fiori 元素应用程序导航到自由式 UI5 应用程序的深层页面时遇到问题，然后 @user6649841 的回答为我的要求提供了大部分解决方案。

在我的例子中，从元素列表报告（应用程序“A”）导航到目标自由式应用程序（应用程序“B”）我根本不希望应用程序 B 中的工作列表/初始页面显示，而是直接转到没有闪烁的初始应用程序屏幕的详细信息页面。

以下对我有用，请注意，尽管它不能解决丑陋的 URL 问题。在我的情况下，我不会对此大惊小怪，因为我的导航返回将导航回元素列表报告（应用程序 A），并且永远不会在应用程序 B 中显示工作列表页面，因此用户永远不会在此 URL 之上进行其他搜索，这将内键和外键不一致

Component.js（在所有标准 sap 代码之后的 init 函数末尾，但在路由器初始化之前）：

var oComponentData = this.getComponentData();
var startupParams = oComponentData.startupParameters;

 if (startupParams && startupParams.myQueryStringParamName && startupParams.myQueryStringParamName[0]) {
    //In my case using hash changer as I dont want the original landing page (default route) to be
    //in the history, so the detail page loads straight away and nav back will cause to nav back to App A
    var hashChanger = sap.ui.core.routing.HashChanger.getInstance();
    hashChanger.replaceHash("detailPage/" + startupParams.myQueryStringParamName[0]);
}
//initialise after the above so the new hash is set and it doesnt initially load the
//page assigned to the default route causing a flickering and nav slide effect
this.getRouter().initialize();

在路由器的初始化方法中查看 UI5 1.48 及更高版本中的 UI5 SDK，您可以传入一个布尔值来告诉它忽略初始哈希，因此可能可以在 UI5 的较新版本中执行更简单的实现

于 2018-08-15T06:35:55.657 回答
0

Component.js 是处理启动参数的正确位置吗？

取决于，如果你有多个视图，并且你想根据传入的参数动态路由。否则，您也可以在特定视图中处理。

你的第二个问题对我来说不是很清楚。

不过，如果您只想了解启动参数的特定情况，那么从 Source App 中设置一些标志以了解请求来自何处并进行相应处理。这样一来，您的正常导航就不会被篡改。

于 2016-02-01T11:15:27.350 回答