PDMLink 9 建立物件時屬性欄位間的互動研究(一)

愈來愈多R9客戶反映使用者需要在建立物件(如文件, 零件)時, 屬性的輸入欄位(attribute's input)間需要有互動關係 相信老Windchill users與老PTC應該對這類的需求再熟也不過了. Template processor時代做這方面的客製司空見慣. 不要說大師兄Wayne, David Su老大, Michael等前輩熟得不要再熟了, 就連客戶那邊的IT自己都玩得興高采烈! 像Joseph, James, Xavier..

PDMLink系列好像從7版開始, 自訂物件類型(Soft type)會自動出現在建立時的類型選項(Type options)中, 而自訂物件類型所包含的自訂屬性(IBA)也會直接顯現在屬性的輸入頁面. 也就是說Windchill R7 為此提出一標準機制, 認為足以供Windchill的黎民百姓使用.

這真是標準的.... 想太多...

這個屬性輸入頁面的第一個問題是很溫柔(以歌手趙傳的語言來說)! 或太溫柔了!!!
這標準界面到 R8 時印象中還是有點陽春(也就是長得有點抱歉).

第二個問題最要命! 因為他這個標準界面是個大黑箱!!! R&D似乎沒打算開放出來讓大家來客製. 個人在過去幾個案子曾經有被逼著做過一些客製, 雖然成功了, 但是必須承認客製的難度比Windchill 626 Template processor時要高, 風險也較大. 更重要的是, 這類的客製, 理論上PTC應該是不負責的.

到了R9 有更多壞消息, Template processor幾乎不見了!!! 取而代之的是WCA. WCA基本上是PTC綜合二年前甚至三年前一些蠻"火"的技術, 關起門來硬搞出來的一套MVC架構, 像個萬花筒一樣. 以周董的說法: "其實還蠻屌的!". 但是上過課的人都認為:更難學了!

至於屬性輸入介面的部分, 有好消息, 也有壞消息. 好消息是這一代界面比較漂亮, 也較好用. 例如日期的輸入終於有日曆了(不過不是萬年曆就是了)! 壞消息是, 這些屬性輸入背後的HTML "INPUT"又更複雜了. 例如做互動效果常需要依賴的輸入名稱(element name), 複雜的嚇人. 例如下圖就是個例子. 對屬性"DemoAttr01", Windchill很貼心的為他取名為...咦? 好像怪怪的是嗎?


"name="components$loadWizardStep$OR:wt.inf.library.WTLibrary:14160$|..."這是什麼東東啊~

其實這張圖我們只看到一小段 後會還有哩


我把其中幾個關鍵字框起來, 至少讓我們分辨的出這個"名字長的不像話的傢伙", 真的是上面那個看來很單純的TextArea! 你若問我為什麼RD要取那麼長的名字? 我只能說我不知道 (其實多少猜得出, 但是算了..)! 但重要的是, 這代表了"互動效果"看來沒像從前那麼好搞定! 這一長串的名字 有些部分還好猜, 有些部分就不一定了? 如下圖:



"4753366976990569820"又是幹什麼的? 好像每次還不一樣?

我在研究這個主題時, 我想過幾種策略. "傳統的"做法: 掌握屬性輸入欄位背後的命名規則(Naming Rule)後再來做加工, 是其中一種. 另一種做法是"訂自己的屬性輸入欄位命名規則". 這種作法還需要配合其他部份的客製: 製做自己的屬性輸入頁面, 並把Windchill後端(server side)建立物件的"Form Proccessor"也同時換成自己客製的Form Proccessor. 簡單來說, 也就是擴大客製Wizard的範圍, 但是說不定比較划算!

由於自訂屬性輸入欄位命名規則與客製Form Proccessor我有一些相關經驗, 所以本月初在訂研究題材時, 我就想試試第一種策略. 目前已有一些進展.

如下面的圖片所示, 我定義了一種文件類型並加入了幾個屬性:







假設使用者希望 demoAttr02 的選項會決定demoAttr03的合法選項. 規則如下:
當 demoAttr02 = option1 時 demoAttr03僅有option1_1, option1_2, option1_3可選
當 demoAttr02 = option2 時 demoAttr03僅有option2_1, option2_2可選
當 demoAttr02 = option3 時 demoAttr03僅有option3_1可選

若用R9預設的建立文件界面 毫無意外 欄位間無互動效果





再加入了一些客製之後, 達到了上述的互動.



關鍵的作法, 下篇文章在介紹.