从程序员的角度来看，fatwire 是什么？
Fatwire 与哪些开源工具包相比？ Fatwire 有一些特殊的优势吗？
导出 Fatwire 并转向免费替代方案有多难？
作为编写 java 扩展的平台有多稳定？
What open source toolkit does fatwire compare to and are there some particular advantages to fatwire?
How hard is fatwire to export out of and move to a free alternative?
How stable is it as a platform to write java extensions on?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
从开发的角度来看，FatWire 可能并不友好。 使用此应用程序在许多网站上工作后，它很容易膨胀，并且变得难以维护。
从用户的角度来看，我们在 UI 方面做了很多努力，这导致了一个功能强大的工具。
从客户的角度来看，所有客户 bar 1（一家大型新闻机构）都对最终结果感到满意。 当使用复杂的逻辑生成菜单或面包屑时，或者当您有大量内容时，FatWire 可能会变慢。 这是一位客户不满意的主要原因。 FatWire 站点经常在负载下挣扎。 有时它被视为满足所有网络需求的解决方案。
因此，FatWire 成功地提供了静态内容和静态内容服务。 半动态内容，但当被迫做完全动态网站时可能会陷入困境（根据我的经验）。
From a development persepective, FatWire can be unfriendly. Having worked on a number of sites using this application it can easy bloat, and become difficult to maintain.
From a user perspective there has been alot of effort in the UI and this has led to a highly functional tool.
From a client perspective all clients bar 1 (a large news agency) were happy with the end result. FatWire can slow when using complex logic to generate menus or breadcumbs for example or when you have a large amount of content. This is the main reason the one client was unhappy. The FatWire site regularily struggled under the load. It sometimes seen as a solution to all web needs.
As such FatWire succeeds in serving Static Content & Semi Dynamic content, but can flounder when forced to do fully dynamic sites (from my experience).
摘自最初的新闻稿：
Firstsite 不是一个产品，除非自 2004 年以来这已经发生了变化（不幸的是我无法查看，因为他们的开发者网站已关闭）。 Fatwire 的内容服务器无法与我所知道的任何开源 CMS 相比。 它的范围更远。 我会一一回答你的问题：
优点 - 很多（不然没人会买，而且价格也不便宜）
在交付方面：可扩展性、细粒度的缓存控制、无状态servlet架构， ....
在后台方面：对资产类型、动态内容属性、查找粒度的安全性和访问控制几乎没有限制，...
在开发方面：具有良好编码效率的智能架构 API、标签库、. ..
开放性
您不能轻易期望在任何两个 CMS 产品（无论开源与否）之间迁移内容。 虽然有多种方法可以使用产品工具或仅在数据库级别以 XML 和其他形式从数据库中提取内容，但我不认为这可以成为支持或反对使用特定 CMS 的论点。 曾经尝试过从 Drupal 迁移到 Joomla 吗？
稳定
从 2000 年到 2004 年，我参与了多个 Fatwire 实现（当时是 OpenMarket Content Server，然后是 Divine Content Server）。 对于《华盛顿邮报》、《纽约时报》和标准普尔网站来说，它足够稳定，我预计今天的稳定性不会成为问题。
From the original press release:
Firstsite is not a product, unless this has changed since 2004 (unfortunately I cannot look, since their developer site is down). Fatwire's Content Server does not compare to any Open Source CMS that I know. It's scope goes much further. I will answer your questions one by one:
Advantages - There are many (or nobody would buy it, and it is not cheap)
On the delivery side: scalability, fine-grained cache control, stateless servlet architecture, ....
On the back office side: virtually no limit to asset types, dynamic content attributes, find-grained security and access control, ...
On the development side: Intelligently architected API with good coding productivity, tag library, ...
Openness
You cannot easily expect to migrate content between any two CMS products, open source or not. While there are ways to extract contant from the database in XML and other forms, using product tools, or simply at the database level, I don't think that this can be an argument for or against using a particular CMS. Ever tried to migrate from Drupal to Joomla?
Stable
I worked on several Fatwire implementations from 2000 to 2004 (back then it was OpenMarket Content Server, then Divine Content Server). It was stable enough for the Washington Post, the New York Times, and the S&P sites, and I would expect stability not to be an issue today.
从开发者的角度来看，Fatwire 确实是一个独特的概念。 它将一切构建在一个非常抽象、极其灵活的智能资产建模框架上，该框架存储在关系数据库中。
应用程序逻辑基于“模板”，它实际上是 JSP 代码片段。 这个JSP代码不像传统的Java，而是标签。 开发人员需要很长时间才能学习这些标签和 Fatwire asset api。 预计熟练的开发人员甚至需要几个月才能开始高效工作。
几乎没有任何可用的样品随产品一起运送。 有广告中的“FirstSite”，但对于该产品的正常使用目的（巨大的复杂网站）而言，它太简单了。 所以几乎一切都必须从头开始构建。
缓存控制被宣传为一项强大的功能。 是的，确实如此，但我们的学习曲线非常长，而且它从来没有像人们想象的那样发挥作用。
即使该产品有广告，也缺少所见即所得的编辑功能。 至少在 2009 年期间，它存在严重的概念问题，实际上阻碍了它在现场环境中的使用。 但对于演示和营销来说，这当然是很酷的功能。 今天它可能会被修复。
总而言之，如果我是预算有限的客户，我会选择任何开源替代方案。 主要是因为 Fatwire 的开发成本很高，因为产品的独特性、缺乏良好的文档以及极长的学习曲线。 当然，产品的价格标签也是需要考虑的因素。
回答问题：如果您从 Fatwire 6.0 迁移到任何开源替代方案，您必须从头开始。 并且在其上构建 Java 扩展是稳定的。
Fatwire is really unique concept from developer point of view. It builds everything on a very abstract, extremely flexible clever asset modeling framework which is stored in relational database.
Application logic is based on "templates" which actually are pieces of JSP code. This JSP code is not like conventional Java, but tags instead. It takes very long from a developer to learn these tags and Fatwire asset api. Expect even months before skilled develpers start to be productive.
Almost nothing useable samples ships along the product. There is advertized "FirstSite" but it is way too simple for the purpose this product is used normally (huge complex sites). So pretty much everything has to be built from scratch.
Cache control is advertized to be one powerful feature. Yes it is, but we had extremely long learning curve and it never worked exactly like one assumed.
Wysiwyg editing has been missed from this product even it is advertized. At least during 2009 it had serious conceptual problems which practically prevented using it in live environments. But it was cool feature for demos and marketing of course. Today it might be fixed.
As a summary and if I were a customer with limited budget, I'd select any open source alternative instead. Mostly because development costs with Fatwire are high due the uniqueness of the product, lack of good documentation and extremely long learing curve. Of course the product price tag is also thing to consider.
And to answer to questions: you have to start from scratch if you move from Fatwire 6.0 to any open source alternative. And it is stable to build Java extensions on.
Fatwire 将内容存储在关系数据库和文件系统中。 根据内容类型（结构化/非结构化），可以对 Fatwire 进行评估。
Fatwire stores content in relation database and file system. Depending on what type of content (structured/unstructured), Fatwire can be evaluated.