列表視圖XML中的Managed =「0」是什麼意思？

我已經編寫了一個Data Extender類和編輯器擴展，可以在瀏覽CME（文件夾和結構組）中的列表時正確顯示項目的其他幾列。我不得不註冊我的類來處理像GetList，GetListSearch，GetListUserFavorites和GetListCheckedOutItems這樣的命令。列表視圖XML中的Managed =「0」是什麼意思？

我注意到，即使在CME下拉列表中加載say，schemas列表時（如創建新組件時，並且您獲得了一個新的組件列表落下）。所以，儘管在這種情況下我不需要額外的數據列，但代碼仍在執行中，並且會降低速度。

看來，這是在這些情況下調用的GetList命令。所以，我不能只是跳過基於命令的處理。於是，我開始研究該類獲得的XML列表，並且我注意到代碼運行時的下拉列表中，XML中有一個Managed="0"。例如：

對於結構組名單：<tcm:ListItems Managed="64" ID="tcm:103-546-4">
的文件夾列表：<tcm:ListItems Managed="16" ID="tcm:103-411-2">
但對於一個架構列表：<tcm:ListItems ID="tcm:0-103-1" Managed="0">
表示用於類別關鍵字值下拉： <tcm:ListItems Managed="0" ID="tcm:103-506-512">

因此，我可以使用這個Managed =「0」作爲標誌來表明正在處理的列表不會顯示我的附加列a nd我可以放棄處理？

來源

2012-08-13 Warner Soditus

感謝您的收拾弗蘭克！ – 2012-08-13 19:04:36

Managed值是可以在裏面OrganizationItem創建哪些項目表示：

64意味着您可以創建
16意味着你可以創建組件
10中，例如將意味着你可以創建文件夾（2）+模式（8）
518 - 文件夾（2）+結構的基團（4）+類別（512）

非組織項目的值爲0。

價值取決於項目本身（你無法創建文件夾頁，例如），以及安全設置您對出版物和組織項目

來源

2012-08-14 09:16:00

謝謝你的解釋Andrey。但是華納案例中的類別不應該說他可以創建關鍵字（假設他有足夠的權利）？ – 2012-08-14 14:12:03

我認爲這隻會在調用它的視圖是類別本身時纔會發生，我認爲這是在獲取創建組件的關鍵字列表時返回的XML。在這種情況下，你將無法使關鍵字 – 2012-08-14 14:14:40

@FrankvanPuffelen是的，它應該，顯然他沒有權利 – 2012-08-14 14:53:12

從以前的經驗和什麼User978511說Managed屬性是項目類型的指示，可以從該列表的上下文創建。

不幸的是，對於任何沒有足夠權限創建項目的用戶，Managed屬性很可能爲0。例如。檢查哪些Managed位於不允許創建頁面或結構組的用戶的結構組中。在這種情況下，它可能是0，這意味着它對你的情況沒有用處。

更新

您可能能夠通過看columns參數更好地達到自己的目標：

context.Parameters["columns"]

在我跑我得到不同的值幾個測試，這取決於關於我是否獲得主列表視圖，樹或下拉列表的列表。

543 
23 
    7

這些值是這些常量的位掩碼（從Constants.js）：

/** 
* Defines the column filter. 
* Used to specify which attributes should be included in XML list data. 
* @enum 
*/ 
Tridion.Constants.ColumnFilter = 
{ 
    ID: 1, 
    ID_AND_TITLE: 3, 
    DEFAULT: 7, 
    EXTENDED: 15, 
    ALLOWED_ACTIONS: 16, 
    VERSIONS: 32, 
    INTERNALS: 64, 
    URL: 128, 
    XML_NAME: 256, 
    CHECK_OUT_USER: 512, 
    PUBTITLE_AND_ITEM_PATH: 1024 
};

所以從我有限的測試似乎下拉菜單請求DEFAULT列，而主列表視圖和樹那裏都有ALLOWED_ACTIONS。這對我來說很有意義，因爲用戶可以與樹和列表視圖中的列表項進行交互，而他們只能在下拉列表中選擇它們。因此，檢查columns參數中是否存在ALLOWED_ACTIONS可能是減少數據擴展程序添加信息的地點數量的一種方法。

來源

2012-08-13 18:37:35

我會嘗試嘗試一下，看看我是否禁用用戶的權限，如果這改變了這個值。不同的問題。有什麼我可以在Data Extender（也許是PipelineContext）中使用來檢測正在執行的GetList命令的「種類」？如果有其他命令用於這些情況，那麼將會很方便，因此我們可以區分正在處理的列表類型。 – 2012-08-13 19:20:02

在允許您的代碼檢測調用它的確切位置和優化緩存之間存在很好的平衡，因爲許多此類位置檢索完全相同的數據。我甚至不確定GetList調用下拉列表是否與列表視圖不同。或者至少：一旦你在列表中顯示了關鍵字，就不需要調用服務器來獲取下拉數據;它只是已經檢索的一個子集。 – 2012-08-13 19:58:12

您可能想看看在'pipelineContext.Parameters [「filter」]'中傳入您的DataExtender的過濾器。過濾器中的「ItemTypes」似乎也給出了請求上下文的一些指示。 – 2012-08-14 00:29:08

我認爲如果您閱讀列表的ID，並且僅對類型2和4（分別爲文件夾和結構組）的列表執行代碼，那麼您將擁有更健壯的解決方案。但不會幫助你與搜索視圖等

來源

2012-08-13 18:42:16

它似乎是我見過的更常見的方法之一：找到方法來識別你不想處理的列表和「如果」那些。即使你無法一次完成所有這些工作，你仍然可以在每次迭代中以更容易管理的風險加快工作速度。在這一點和針對您添加的信息的積極緩存策略之間，您通常可以獲得合理的性能表現。當然，沒有任何東西能夠擊敗***而不是將自定義列添加到列表中。所以你應該總是首先考慮這個選擇......並且最後。 – 2012-08-14 00:00:24

@FrankvanPuffelen：完全同意。然而，戰鬥失敗了（現在）。這些衆多的附加列被認爲是商業用途所必需的。 – 2012-08-14 14:09:39

不幸的是CME不能提供正確的現在這種粒度級別允許您在數據擴展器中告知特定WCF API調用的來源。我們的WCF API還沒有上下文感知。它可能在未來發生變化。

Trusting Managed =「0」不是一個好主意。原因是模型列表是客戶端緩存每個過濾器。在當前的設計中，過濾器具有與CM相關的數據，並且與請求被觸發的上下文無關。通常情況下，客戶端用戶界面在任何時候都可以重新使用緩存的模型數據。例如，可以在CME儀表板中使用相同的模型列表，並將一個下拉控件放置到某個項目視圖中，但使用不同的xml列表定義：第一個列表定義的列數比後者多。他們對相同數據的看法基本不同。

因此，您可能想爲您的問題考慮不同的解決方案。現在......這些附加列背後的數據來自哪裏？是Tridion CM還是第三方提供商？有時，Web服務器緩存可能會提供一種可接受的方式來改善響應時間。但那是你應該評估和決定的那種設計。

來源

2012-08-29 09:55:39 lnaie

謝謝！我提交了一個增強請求，以便可以告訴GetList命令的來源。對於我們的具體實現，所有數據來自Tridion CM，因此緩存並不合適。我們添加的列是：修改者，版本，審批狀態，鎖定者，發佈日期。我有一天喜歡能夠做的是讓內容作者能夠根據需要設置偏好來打開或關閉附加列。關閉它們顯然會加快它們在CME中的導航，打開它可以讓他們看到他們需要的其他信息。 – 2012-08-30 11:10:27

列表視圖XML中的Managed =「0」是什麼意思？

回答

相關問題