马蒂斯还是冰屋？

Question

我们陷入两难境地;使用Matisse或Jigloo开发桌面应用程序..

马蒂斯有这种XML格式文件我们害怕以后维护，我们甚至不知道MyEclipse是否应该进一步支持马蒂斯，甚至Netbeans - 你认为他们会放弃对马蒂斯的操作系统支持吗？

或多或少Jigloo和Matisse有类似的行为，虽然Jigloo服从更多设计师的愿望，Matisse不时有这种奇怪的对齐行为。

Jigloo生成可以编辑的Java代码，这反过来会导致可视化编辑器无法绘制表单。这可能就是为什么Matisse希望以更稳定的XML形式定义元素，从而生成Java代码。

如果在实例化GUI元素时出现错误，Matisse将无济于事，因此放置自定义元素也可能是噩梦。

在Jigloo中输入代码时，可视化编辑器喜欢删除图片，因此您必须等待图片在编辑代码后显示。在Matisse中，您可能会在课堂上出现错误并仍在编辑GUI。

请通过投票来帮助我们，您更喜欢什么？为什么。

Answer 1

请不要使用任何一个！与this answer一样，这是我的强烈意见（在编写Swing GUI 10年之后），使用GUI构建器，除了最边缘的情况之外，一个坏主意。 手动编码您的GUI！

• 无论您选择马蒂斯还是冰屋，它都不是标准，会失宠，会有更好的工具出现。此时，您将拥有几乎无法维护的遗留代码。这已经发生在Java GUI构建器历史上的重要时期

• 您应该避免强迫您的开发人员使用一个IDE，并且在查看GUI代码时期望开发人员切换到特定IDE是一个巨大的开销。他们会感到沮丧，因为他们不记得键绑定，项目设置已过时，他们有错误的版本安装等。人们将在没有构建器的情况下快速修复。此时您的代码在您选择的IDE和GUI构建器istelf 中都不可维护！整件事情一团糟。

• 根据我的经验，设计GUI并不是一项特别繁重的任务，并且可能占应用程序总开发时间的不超过5-10％。即使最初使用Matisse或Igloo为您提供了比手动编码GUI 50％的时间优势，这在宏观方案中是无足轻重的。当然不值得隐藏的成本和即将发生的维护灾难

• GridBagLayout 并不难。它只是不是！事实上，这很简单。这将花费您几分钟的时间来学习，之后您将永远不会回头。您的GUI看起来就像您希望它们看起来一样，因此您的代码将更易于维护。使用GridbagLayout！

我花了很多时间向人们发出警告，并且证明是正确的。

Answer 2

我也不愿意。到目前为止，我发现的最好的东西是Instantiations Swing Designer。它不是免费的，但也不贵。它支持所有主要的Swing布局，并且除了纯Java代码之外，不会创建任何其他工件。

如果您感兴趣的话，这是link。

Answer 3

我更喜欢马蒂斯，因为Netbeans得到了Sun Microsystems的支持，并且该项目在近期期货中被废弃的可能性似乎很低。

另外，我不知道你的项目的大小，但我已经开发了一些小项目，我个人使用matisse来查看布局的外观，然后使用Miglayout库进行编码。它大大增加了编码量，但提供了良好的控制和灵活性。并且这个库有可能包含在Java 7中，因此嵌入到Matisse中。

Answer 4

我个人曾经有过几次支持Matisse表单的XML文件与代码不同步而不得不求助于备份以使其再次运行。这足以吓跑我了。不过，我对Jigloo没有经验。

我目前的项目广泛使用TableLayout。它很容易理解（我尝试过的所有布局管理器）都能维护。我没有在Java的GUI设计中找到任何其他解决方案，我觉得比手工编写GUI更舒服。展望未来，它似乎是对我的GUI进行编码的最佳“面向未来”的方式。

我同意Chintan使用Matisse或类似方法来模拟你的设计，然后将布局转换为另一种布局（如TableLayout）。就个人而言，我喜欢用铅笔和纸来做大部分工作。不完全是高科技，但它完成了工作。

Answer 5

我更喜欢Netbeans Matise。即使不可能编辑生成的代码，使用Mattise设计复杂的屏幕要容易得多（因为FreeForm布局）。

Answer 6

我没有尝试过Jigloo，但我会在混合中投出第四个。

JFormDesigner是我用过的最好的Swing UI设计师。 像Matisse一样，它确实创建了XML表单文件，但这是该工具的唯一不利之处。

它支持所有标准布局管理器，以及一些流行的布局管理器（例如JGoodies FormLayout）。它有IntelliJ和eclipse的插件，也可以作为一个独立的工具运行。

以下是link

HTH

柯恩

Answer 7

当您弄乱工具生成的文件时，您可以期待什么？混乱，不是吗？ 这是开发人员忘记的非常重要的 。

以马蒂斯为例。它为您生成XML文件，并为您生成.java文件。 为什么地球开发人员开始改变这些类？ 后来他们抱怨说一切都搞砸了，他们指出马蒂斯是有罪的，因为马蒂斯不做A或不做B.马蒂斯唯一有罪的是无法解决开发商所提出的混乱问题。 。这是人工智能领域的问题，我个人不希望很快解决任何问题。

它有一个或多或少的简单解决方案：OOP。

我解释说：OOP最重要的概念之一是“责任”，这意味着某个类在更广泛和更复杂的问题领域中具有有限且明确的责任。 因此，Matisse为您生成了UI，它基本上包含UI元素，事件处理程序等。

然后你说：嗯......我需要为它添加一些逻辑，否则UI是无效的。真正。这是另一项责任，不能 永远在Matisse生成的同一个类中实现。因为任何一个人都懒惰或者不理解“责任”在OOP中意味着什么，人们就会实现他们所需要的，添加许多变量并在一个绝对不负责业务逻辑的类中促进各种疯狂。

通过像继承这样非常简单的事情，您可以在扩展类中分离业务逻辑。基类是马蒂斯生产的基类。扩展的是手工实现的类，包含事件处理程序的实现，UI元素的初始化等等。

很多开发人员都想手动编辑Matisse生成的.java文件。 黄金法则是：从不，从不手动编辑.java文件。马蒂斯为您提供定义所需内容的方法，并随叫随到。永远不要编辑由Matisse生成的资源（.xml和.java），你保证它（Matisse）能够再次加载它，以防你将来需要更改GUI。可能你会发现自己想要直接编辑.java甚至.xml文件。请抵制这种诱惑，教育自己;你将来会感谢自己。

所以...你可以使用你想要的任何工具或任何提供最性感的UI元素。 如果您无法将UI与业务逻辑分离，则所有工具都将失败。 如果您作为程序员成功完成主要任务，那么所有工具都将成功：生成合适的代码。