blocks|key|353195|text|我已经使用GWT完成了几个小项目。下面是我喜欢它的一些地方：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|353196|353197|默认情况下它是ajax，所以我不需要让它做ajax，它只是使用GWT出现的。|ordered-list-item|353198|它很好地分离了客户端代码和服务器端代码。|353199|我可以使用junit|353200|对我的客户端代码进行单元测试它可以让你构建清晰、快速的应用程序，这在很大程度上是因为它是ajax。|353201|<代码>G29|353202|我不喜欢的东西：|353203|353204|有些东西并不像预期的那样工作。例如，我见过点击事件没有按预期触发的情况，所以我不得不对运行在eclipse中的tomcat执行workaround.|353205|Auto-deploy，有时会停止工作，我永远也找不到原因。|353206|353207|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Z|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|11|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|12|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|13|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|14|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|Q|3|R|5|E|7|16|8|@]|9|@]|A|$]]|$1|S|3|T|5|E|7|17|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|19|8|@]|9|@]|A|$]]]|W|$]]

I've used GWT for a couple small projects. Here are some things I like about it:

<ol>
<li>It's ajax by default, so I didn't have to make it do ajax, it just came along with using GWT.</li>
<li>It's got good separation of client versus server-side code.</li>
<li>I can unit-test my client code using junit</li>
<li>It lets you built crisp, snappy apps, largely because it's ajax.</li>
</ol>

Things I don't like:

<ol>
<li>Some things don't work as expected. For example, I've seen cases where click events didn't fire as expected, so I had to do a workaround.</li>
<li>Auto-deploy to tomcat running in eclipse sometimes just stops working, and I could never figure out why.</li>
</ol>

blocks|key|348093|text|我要问的最大的问题是，你为什么要改变表示层？这是一个非常昂贵的成本，我可以看到一种技术的好处超过了其他技术，就像改变成本一样……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|348094|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The biggest question I'd ask is why are you changing presentation layer? That's a very expensive cost and I can see the benefits of one technology outweighing the others by as much as the cost to change...

blocks|key|349490|text|我想知道你是否有一个不同于web客户端的服务层，web控制器只是简单地调用它来完成他们的工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|349491|如果这样做，则可以将web+UI技术的选择与后端解耦。如果它被公开为合同优先的web服务，你可以让不同的应用程序共享它。只要您的客户端可以发送和接收XML，它们就可以与您的服务交互。想切换到Flex吗？不用担心-将其指向服务并呈现XML响应。|349492|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'd wonder if you a have a service layer that's distinct from the web client, something that the web controllers simply invoke to get their work done.

If you do, the choice of web UI technology can be decoupled from the back end. If it's exposed as a contract first web service, you can have different apps share it. As long as your clients can send and receive XML they can interact with your services. Want to switch to Flex? No worries - point it at the service and render the XML response.

blocks|key|3128891|text|简而言之：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3128892|=+JSF+=|3128893|优点：|3128894|良好的集成开发环境组件architecture;|3128895|many库和tools;|unordered-list-item|3128896|
|3128897|somewhat支持|3128898|3128899|缺点：|3128900|3128901|很重，在CPU/内存和学习曲线上都是如此；|offset|length|style|BOLD|3128902|当某些东西不能按预期工作时，很难调试|3128903|3128904|=+WICKET+=|3128905|3128906|3128907|lightweight;|3128908|sensible模板系统；|3128909|良好教程；|3128910|3128911|3128912|与tutorials;|3128913|development团队一样，|3128914|参考文档的组织和深度也不是很好，特别是在成为和孵化项目时。这导致了在框架的重要方面的混乱，当时我不得不切换到另一个框架，因为这个……|3128915|3128916|3128917|entityMap^0|0|0|0|0|0|0|0|0|0|0|A|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1S|8|@]|9|@]|A|$]]|$1|M|3|N|5|J|7|1T|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1V|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|1X|8|@$U|1Y|V|1Z|W|X]]|9|@]|A|$]]|$1|Y|3|Z|5|J|7|20|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|22|8|@]|9|@]|A|$]]|$1|13|3|E|5|6|7|23|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|15|3|16|5|J|7|25|8|@]|9|@]|A|$]]|$1|17|3|18|5|J|7|26|8|@]|9|@]|A|$]]|$1|19|3|1A|5|J|7|27|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|28|8|@]|9|@]|A|$]]|$1|1C|3|Q|5|6|7|29|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|2A|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|J|7|2B|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|J|7|2C|8|@]|9|@]|A|$]]|$1|1J|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1K|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1L|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]]|1M|$]]

In short:

= JSF =

PROS:

<ul>
<li>component architecture;</li>
<li>many libraries &amp; tools;</li>
<li>somewhat good IDE support</li>
</ul>

CONS:

<ul>
<li>heavy weight, both in CPU/memory and learning curve;</li>
<li>when something doesn't work as expected, it's difficult to debug</li>
</ul>

= WICKET =

PROS:

<ul>
<li>lightweight;</li>
<li>sensible templating system;</li>
<li>good tutorials;</li>
</ul>

CONS:

<ul>
<li>reference documentation is not so well organized and deep as are the tutorials;</li>
<li>development team had some serious difficulties, especially when becoming and incubated project. This lead to confusion on important aspects of the framework, at that time I had to switch to another framework because of this...</li>
</ul>

blocks|key|3128960|text|我的观点非常偏向Wicket，因为我在JSP上被太多次绊倒之后，已经使用它一段时间了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3128961|Wicket+PROs:|offset|length|style|BOLD|3128962|layout和基于code.|3128963|Component的真正分离，这意味着站点元素的高度可重用性；例如，您可以创建带有自动标签和样式的美化表单，只需在组件的构造函数中更改它的DAO对象，它就可以在另一个project.|unordered-list-item|3128964|Excellent中完全重用，支持Ajax，|3128965|和各种框架，通常直接开箱即用，更重要的是，它不依赖于任何其他东西，除了slf4j/log4j之外，一切都是可选的|3128966|3128967|3128968|Wicket缺点：|3128969|3128970|开发在一般情况下有一些混乱，Wicket泛型现在有点混乱，尽管它们在1.4|3128971|中已经被清理了很多，一些组件(如Form.onSubmit())需要广泛的子类化或匿名方法来轻松地重写注入行为。这在一定程度上是由于Wicket强大的基于事件的设计，但不幸的是，这也意味着很容易用Wicket弄乱代码。|CODE|3128972|3128973|随机缺点：(也就是说，我没有用过，但这些是我的观点和/或我听说过的东西)|3128974|3128975|GWT是基于JavaScript的，这在我听起来很愚蠢。主要的问题是它让我想起了太多的JSP:s和它的自动生成的类，这些类是horrible.|3128976|Tapestry，没有以一种可以在两者之间轻松验证的方式正确地分离标记和代码，这将在未来导致问题。|3128977|3128978|entityMap^0|0|0|C|0|0|0|0|0|0|0|0|9|0|0|0|G|F|0|0|0|5|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1C|8|@$D|1D|E|1E|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1F|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1G|8|@]|9|@]|A|$]]|$1|M|3|N|5|L|7|1H|8|@]|9|@]|A|$]]|$1|O|3|P|5|L|7|1I|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1L|8|@$D|1M|E|1N|F|G]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|V|3|W|5|L|7|1P|8|@]|9|@]|A|$]]|$1|X|3|Y|5|L|7|1Q|8|@$D|1R|E|1S|F|Z]]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1U|8|@$D|1V|E|1W|F|G]]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|14|3|15|5|L|7|1Y|8|@]|9|@]|A|$]]|$1|16|3|17|5|L|7|1Z|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|20|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|21|8|@]|9|@]|A|$]]]|1A|$]]

My opinions are quite heavily biased towards Wicket because I've been using it for a while after tripping over JSP mines far too many times.

Wicket PROs:

<ul>
<li>True separation of layout and code.</li>
<li>Component based which means high reusability of site elements; For example you can create prettified form with automatic labeling and CSS styles and everything and just by changing it's DAO object in the component's constructor it's completely reusable in another project.</li>
<li>Excellent support for things like Ajax, Portlets and various frameworks in general directly out-of-the-box AND more importantly it doesn't rely on anything else than slf4j/log4j to work, everything's optional!</li>
</ul>

Wicket CONs:

<ul>
<li>Development has some confusion about things in general and Wicket generics are a bit of a mess right now although they've been cleaned a lot in 1.4</li>
<li>Some components (like <code>Form.onSubmit()</code>) require extensive subclassing or anonymous method overriding for injecting behaviour easily. This is partly due to Wicket's powerful event-based design but unfortunately it also means it's easy to make a code mess with Wicket.</li>
</ul>

Random CONs: (that is, I haven't used but these are my opionions and/or things I've heard)

<ul>
<li>GWT is JavaScript based which sounds stupid to me. Main issue is that it reminds me too much of JSP:s and its autogenerated classes which are horrible.</li>
<li>Tapestry doesn't separate markup and code properly in a manner which could be easily validated between the two which will cause problems in the future.</li>
</ul>

blocks|key|353275|text|那Stripes呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|353276|entityMap|0|LINK|mutability|MUTABLE|url|http://www.stripesframework.org/^0|1|7|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

What about <a href="http://www.stripesframework.org" rel="nofollow noreferrer">Stripes</a>?

blocks|key|353287|text|我的选择是Wicket。已经使用过，并且提供了极好的可重用性。它有一个最活跃的论坛/邮件列表。作为一个问题，它将在几分钟内得到回答。它对AJAX有很好的支持。Wicket的一个常见缺点是学习曲线陡峭。好吧，这些都是老年骗局之一，现在已经不再有价值了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|353288|JSF:最好远离它。另一个团队在JSF上开发了一个项目，现在正在考虑在我们成功使用Wicket之后转向Wicket。|353289|@Megadix:就像你说的，一开始文档很差，但现在不是了。Wicket的开发者写了一本很好的书，叫做Wicket+in+Action。网站上提供的示例代码也是一个很好的入门和学习的地方|353290|entityMap^0|5|6|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|K|$]]

My pick would be Wicket. Have used it and is gives excellent re-usability. It has one of the most vibrant forum/mailing list. As a question and its gonna be answered in minutes. It has excellent support for AJAX. One of the usual cons attributed to Wicket is the steep learning curve. Well those were one of the old age cons which hold no value anymore now.

JSF: Better stay away from it. Another team which developed a project on JSF is now thinking to shift to Wicket after our success with it. 

@Megadix: Like you said the documentation was poor in the beginning, but not any more. There is an excellent book called Wicket in Action written by the developers of Wicket. The sample code provided on the site is also a good place to start and learn

blocks|key|353295|text|请看我对Wicket和Tapestry5的比较：Difference+between+Apache+Tapestry+and+Apache+Wicket。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|353296|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/657352/difference-between-apache-tapestry-and-apache-wicket/658177#658177^0|O|1G|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

See my comparison of Wicket and Tapestry 5: <a href="https://stackoverflow.com/questions/657352/difference-between-apache-tapestry-and-apache-wicket/658177#658177">Difference between Apache Tapestry and Apache Wicket</a>.

I'm currently working on a web app that makes heavy use of JSF and IceFaces. We've had some discussions of moving to another presentation layer, and I thought I'd take the discussion out into SO and see what the experts think. 

I'm curious if anyone could weigh in on the pros and cons of the various Java presentation layer technologies. If you've only worked with one, say why you love it or hate it. If you've worked with several, give your impressions of how they stack up against each other.

Our technologies under consideration are: 

<ul>
<li>IceFaces</li>
<li>JSF (without IceFaces)</li>
<li>GWT (Google Web Toolkit)</li>
<li>Wicket</li>
<li>Tapestry</li>
</ul>

And if I'm missing anything from my list, let me know. 

Thanks!

Pros and Cons of Various Java Web Presentation Layer Technologies

集成开发环境

单元测试

服务器

Java

我目前正在开发一个web应用程序，它大量使用了JSF和IceFaces。我们已经讨论了转移到另一个表示层，我想我应该把讨论带出去，看看专家们是怎么想的。我很好奇是否有人可以权衡各种Java表示层技术的优缺点。如果你只用过一个，说出你为什么喜欢或讨厌它。如果你和几个人一起工作过，给出你的印象，他们是如何相互竞争的。我们正...

问各种Java Web表示层技术的优缺点
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问各种Java Web表示层技术的优缺点EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问各种Java Web表示层技术的优缺点
EN