從程序員的角度來看fatwire是什麼？

Question

fatwire與fatwire相比有哪些開源工具包，fatwire有一些特別的優勢嗎？

fatwire有多難以導出並移至免費替代品？

作爲編寫Java擴展的平臺有多穩定？

Answer 1

從發展的角度來看，FatWire可能是不友好的。在使用這個應用程序的許多網站上工作後，它可能容易膨脹，並且變得難以維護。

從用戶角度來看，在UI中已經付出了很多努力，這導致了一個功能強大的工具。

從客戶的角度來看，所有的客戶bar 1（一家大型通訊社）都對最終結果感到滿意。例如，當您使用複雜的邏輯生成菜單或麪包時，或者當您有大量內容時，FatWire可能會變慢。這是一位客戶不高興的主要原因。 FatWire網站經常在負載下掙扎。它有時被看作是解決所有網絡需求的解決方案。由於此類FatWire成功地提供了半動態內容，但在強制執行完全動態網站（根據我的經驗）時可能會出現fl ounder現象。

Answer 2

從最初的新聞稿：

FatWire Software公司宣佈推出FirstSite的 ，這是一套工具 和最佳實踐，幫助 公司使用FatWire公司的Content Server 得到他們的第一個網站或 應用程序運行很快，而 提供了未來 擴展的基礎。 FirstSite包括 收集的標準模板和共同 大多數網站 網站組成，具有 文檔，培訓，豐富 開發者社區相結合，和最佳實踐 方法。 FatWire及其 解決方案合作伙伴正在使用FirstSite 作爲開發基於內容的 特定垂直市場應用的基礎。只有 未成年人，化妝品改建， 開發人員可以使用代碼 FirstSite實施的第一個站點， 同時學習如何 利用內容服務器的能力， 諸如動態內容傳送， 個性化，緩存和產品 目錄。

Firstsite不是一個產品，除非自2004年以來這已經改變（不幸的是我不能看，因爲他們的開發人員網站已關閉）。 Fatwire的內容服務器不會與我知道的任何開源CMS進行比較。它的範圍進一步擴大。我會回答你的問題一個接一個：

優勢 - 有許多（或者沒有人會買它，它是不便宜）

在交貨方面：可擴展性，細粒度的高速緩存控制，無狀態的servlet架構，....

在後臺方面：幾乎沒有限制的資產類型，動態內容的屬性，發現細粒度的安全性和訪問控制，...

在開發方面：智能具有良好編碼效率的架構API，標籤庫，...

開放

你不能指望輕鬆遷移到任何兩個CMS產品，開源與否之間的內容。儘管有辦法從XML和其他表單中使用產品工具或簡單地在數據庫級別從數據庫中提取內容，但我不認爲這可能是爭取或反對使用特定CMS的理由。曾經試圖從Drupal遷移到Joomla？

穩定

我曾在幾個FatWire公司實現2000至2004年（當年很OpenMarket內容服務器，然後神州內容服務器）。它對於華盛頓郵報，紐約時報和P站點來說已經足夠穩定了，我希望今天穩定不成問題。

Answer 3

從開發人員的角度來看，Fatwire是真正獨特的概念。它將所有內容構建在一個非常靈活的非常靈活的聰明的資產建模框架上，該框架存儲在關係數據庫中。

應用程序邏輯基於實際上是JSP代碼片段的「模板」。這個JSP代碼不像傳統的Java，而是代替標籤。學習這些標籤和Fatwire資產api需要很長的時間。甚至在熟練的開發人員開始具有生產力之前甚至還有幾個月。

幾乎沒有可用的樣品在產品上運送。有廣告的「FirstSite」，但它對於通常使用這個產品來說太簡單了（巨大的複雜網站）。所以幾乎所有的東西都必須從頭開始構建。

緩存控制廣告是一個強大的功能。是的，但是我們有很長的學習曲線，它從來沒有像假設的那樣工作。

Wysiwyg編輯已被忽略從這個產品，即使它被廣告。至少在2009年期間，它有嚴重的概念問題，實際上阻止在實際環境中使用它。但它當然是演示和營銷的很酷的功能。今天它可能是固定的。

作爲一個總結，如果我是一個預算有限的客戶，我會選擇任何開源替代品。主要原因是由於產品的獨特性，缺乏良好的文檔記錄和極長的學習曲線，因此Fatwire的開發成本很高。當然，產品價格標籤也是需要考慮的事情。

並回答以下問題：如果您從Fatwire 6.0遷移到任何開源替代品，您必須從頭開始。在Java上構建Java擴展是穩定的。

Answer 4

Fatwire將內容存儲在關係數據庫和文件系統中。根據什麼類型的內容（結構化/非結構化），Fatwire可以被評估。