t*******e
发帖数: 684 | 1 上次和goodbug等几位讨论到了如何在wicket中把的html tag attribute值变成动态的
问题, 正好看到了这一章，就先说一下，以免忘了。实际上还有很多收获，等书看完再
说了。
JSP中用EL
Hello #{user.name}
Wicket一切都在Java code里
Hello user
1. onComponentTag method of Wicket components
webpage.add(new Label("label", "Hello "+user.getName()){
protected void onComponentTag(ComponentTag tag)
{
super.onComponentTag(tag);
tag.put("style", (user.isActive())?"color:blue":"color:r |
|
F****n
发帖数: 3271 | 2 从UI开发的角度来说，UI的LOGIC（而不是应用LOGIC），就是V的这部分大概可分为三
个层次：
1. Layout和Appearance;
2. Static relations among components / data (such as component hierarchy)
3. Dynamic relations among components / data (such as event management).
Wicket相当于在第一个Level实现了Declarative，XUL相当于在第二个LEVEL实现了
Declarative。目前没有FRAMEWORK能在第三LEVEL实现Declarative。
我觉的你要是看了ZK的设计，就会觉得Wicket还不算完美。ZK的设计要比Wicket要
flexible的多, 能整合html, JS, xhtml, JSP, JSF，XUL, 甚至无template的Richlet
。功能上讲Wicket相当于ZK的一个子集。
最后, Struct倒不一定失败，我的经验是MVC不一定能代替Mixed HTML&JS, |
|
g*****g
发帖数: 34805 | 3 Wicket is a better framework "framework wise", and I would say much
better. e.g. It's easy to write your own component in wicket and
reuse it in future. It's very difficult to write a custom component
in jsf. wicket doesn't use xml at all, and it uses plain html, which
is easier for preview than either jsp or facelet. wicket also has a
very smart way to do layout.
In short, jsf has to have seam just to not suck. That being said,
it's a standard and industry support is always nice to have. Just |
|
F****n
发帖数: 3271 | 4 对Wicket或类似的FRAMEWORK来说，有一点值得注意，据说Wicket把XUL拿掉了，强调用
POJO的而不是Declarative UI Language. 我觉得这是一大退步。实际上把Declarative
UI和HTML混为一谈是非常可笑的。以前做过大量Swing Programming 的人都知道，用
JAVA做UI是非常MESSY的，Declarative UI（如COCONUT那个）应该是大方向。Wicket这
种把DSL丢掉的做法更象一个MARKET DECISION，短时间内能赢的那些HATE HTML JS的
DEVELOPER（like me)，但时间长了，会发现实际上回到了老路。 |
|
F****n
发帖数: 3271 | 5 Like I said before, ZK is a bit like C++, which is flexible but can be
easily abused. But you certainly can avoid zscript and do it in the same way
as Wicket. The problem of Wicket is, it pre-assume scriplet as evil, which
is not. It is evil only when abused. In other times, it provides a very
convenient way to invoke java functions. A cynical thought: they cut script in Wicket so they have to bash it otherwise people would think they are not smart enough to incorporate it in the framework:)
XUL |
|
t*******e
发帖数: 684 | 6 I was told a wicket project in a company failed due to performance related
issues. Unlike most of the performance issues caused by data access logic,
the problem turned out to be related to the fact how wicket manages UI
component state. The writer of "wicket in action" made a statement about
state management that is the opposite from what most people believe, "going
to the database with each request to save memory". Effectively all data
objects are request scoped, except for their primary keys, |
|
g*****g
发帖数: 34805 | 7 This is in a comparison of JSF vs. Wicket.
http://ptrthomas.wordpress.com/2007/05/14/a-wicket-user-tries-jsf/
I manage a project that started off innocently enough a year and half ago
using SpringMVC and JSTL markup for the presentation tier. Acegi managed
authentication/authorization. We soon added Displaytag for handling table
layouts, Struts-Menu for a menubar, and SiteMesh for page decorating.
Eventually we felt the need for more control over page navigation so we
added SpringWebflow and fou |
|
g*****g
发帖数: 34805 | 8 说不上吧，wicket没有扔掉dsl, gui就是xhtml，java代码里面基本不涉及look&feel
的部分。wicket强调的是简化component的描述，不使用XML来声明component，而直接
用类和变量实现了。
Declarative |
|
F****n
发帖数: 3271 | 9 Wicket里头XHTML只是用来specify id, 相当于一些hooks和placeholders, 基本的UI
Logic（跟Look and Feel是两码事）还是在Java里头做的。Wicket的advocates说其目
的是把Web UI开发变换成类似于Swing Programming，我只是觉的这个说发非常可笑...
like Swing programming is heaven. |
|
F****n
发帖数: 3271 | 10 其实就如我上面说的，Wicket靠XHMTL和CSS在Layout上实现了DSL，但在component
relations (如component tree)上还是用JAVA。这个问题用XUL就能很容易的解决，但
Wicket的Design没采用。
. |
|
g*****g
发帖数: 34805 | 11 I think XUL is for multiple platform GUI development, like making
similar thick and thin clients at the same time. I don't really see
the benefit of XUL in sole web development.
This ZK example
http://www.zkoss.org/doc/step%20by%20step_p2.dsp
Show all the bad smell I want to avoid, it's almost like using scriptet
in JSP. With wicket, you can't do that at all. True previewable 1:1
mapping of components is what I like about wicket. |
|
|
k***r
发帖数: 4260 | 13 Yeah I was using that for an example. Let me quote the
original article here:
"There are Wicket classes that won't work with bookmarkable
URLs. For example, if you want to use the Wicket "paginator"
(think the bottom of Google search results), your URLs have
to look ugly. So if you want pagination on your site with
pretty URLs, you're going to have to write it yourself.
And that goes for a lot of its other APIs." |
|
g*****g
发帖数: 34805 | 14
At the very worst, it's about immediate support, not capablity.
If there's a high demand on that one. Wicket can come out
something like that quickly, or it's not very hard to write
one yourself. Now think about this again, it's not even easy
to do pagination with action frameworks and you get 100 ad-hoc solutions
in 100 applications. In wicket, it's pretty a one liner, that's
the power of component.
Good frameworks make simple things simple, difficult things possible,
But not all simple things |
|
g*****g
发帖数: 34805 | 15
You just have more widgets in web development, more customizable
look and feel with CSS. You can always have the functionality running
and let designers deal with the CSS, you can even do it at the
same time, that's exactly what wicket wants to do. You put your
components in the html page and let designers deal with it.
wicket's preview ability is not perfect, but it's the best in
any frameworks I know.
This is not true, it's the same textfield, buttons, dropdown box we
are dealing with, with o |
|
|
t*******e
发帖数: 684 | 17 wicket in action by manning。
Wicket是个designer friendly web framework. 如果你的team里有html designer，可
以用，否则直接用RIA framework会方便很多。 |
|
|
m******t
发帖数: 2416 | 19 I for one never buy any quantitative claims on productive gains, as far as
software development is concerned.
And, no, I have not used wicket in any real project, so, sorry, I didn't
really have any thoughts to share, other than trashing your thread. 8-) |
|
|
g*****g
发帖数: 34805 | 21 I am quite satisfied with Spring MVC with my project,
but when I start clicking with AJAX, I reallize it's
really complicate. Wicket seems to be able to do
fancy stuff quickly since most are done in pure java,
quite like Swing of Web. |
|
g*****g
发帖数: 34805 | 22 My gut feeling is that Wicket makes it right.
JSTL, struts, or most other frameworks have iteration, conditional
in JSP or JSP kind of makeup, which is certainly logic.
I don't mind xml configuration in spring, but when it goes into
Spring Webflow, it's logic and states in XML.
YUI and other AJAX libs, are packing too much logic in client side, and
in many cases difficult to maintain states across requests.
I'd like to see the bare minimum on client side, and shift all others
to the server side, |
|
|
t*******e
发帖数: 684 | 24 真正比较流行的Java Web Frameworks有个7-8种，
Struts 2 (WebWork 2)
Struts 1
Spring MVC
JSF
WebWork 1
Stripes
Tapestry
Wicket |
|
t*******e
发帖数: 684 | 25 刚看到书上的一段话，感觉可以用来界定conventional web frameworks和ajax-
centric frameworks.
"Wicket's approach to Ajax is that Ajax is optional."
如果对于一个web framework, Ajax是optional的, 就是conventional的web framework
. 个人感觉conventional web framework对HTML designer更加friendly. |
|
F****n
发帖数: 3271 | 26 用ZK理论上可能，用GWT不一定，因为ZK可以Wrap HTML和JS, 所以ZK有点象C++, 而GWT
, Wicket等更象Java。
但实际应用中这些Framework问题都不少，要继承Legacy Code的话还是不要用。 |
|
t*******e
发帖数: 684 | 27
Declarative
我以前做过一年Swing的开发，比web programming恶心许多倍。但你对wicket的说法不
很准确。那么多的
web framework都是有针对性的，具体用那个，要根据团队，项目要求等优化决定的。 |
|
g*****g
发帖数: 34805 | 28 Logic在Java里做有什么问题吗？我觉得Logic在java里做很好，
所谓MVC, html/jsp/jsf等等本来就应该是View而已。类struts
风格的tag/jstl，把C做进了V，本身就是很大的错误。
Swing programming, MVC是做得很清楚的。问题在于V的部分
用java实现，对designer来说设计和修改都不方便。而wicket
V的部分是xhtml，我觉得这个设计接近完美。javafx实际上也是
往这个方向靠拢。
.. |
|
t*******e
发帖数: 684 | 29 用了一个月的时间, 把书很仔细的看完了.
感觉wicket象是个HTML designer设计的web framework，而不是由Java programmer设
计的. 优点大都是针对HTML和Search Engine的, Java coding的负担反而加重了不少.
最喜欢的几点,
1. Detached Model, 很有意思, 但也是个pitfall
2. Page Mounting and URL encoding, 针对Search Engine优化
3. Testing support, 比Struts2强太多了
4. Plain old HTML, 但不是那么重要
5. Page histories are serialized into file systems, browser back button
support
6. Bookmarkable links, 空壳，具体执行还要靠developers.
7. Null safe component model bindings. 一般不怕NullpointerException.
不喜欢的几点,
1. 手写P |
|
t*******e
发帖数: 684 | 30 We surely can load configurations from properties files, but it still
requires extra coding to set those values through Wicket APIs. Building a component
tree in Java and lining it up with the Markup DOM tree could be error-prone also. |
|
g*****g
发帖数: 34805 | 31
way
which
script in Wicket so they have to bash it otherwise people would think they
are not smart enough to incorporate it in the framework:)
Personally I've yet to see a single instance in which scriptlet can't
be avoided. It may be convenient for some quick prototype, that's it.
No, I don't like html, but XUL isn't supported by all browsers either.
I doubt Dreamweaver supports it. The point is, we don't write html,
designers do. I'd rather let them use their favorite editor. And we
developer |
|
g*****g
发帖数: 34805 | 32 I don't know how that would work out in real project. So you mean
designers write the html/mockup image, and developers translate to
XUL? Now how about slight tweak seen needed by designers, or some
cross browser issues that they need to do some hack?
Until XUL is natively supported by browser, it won't be pretty going
that way.
I like Wicket's philosophy, because programmers can lay down the components,
and designers and programmers can work in parallel without worrying stepping
on each other' |
|
c*****t
发帖数: 1879 | 33 I don't care about Wicket, but if you guys are to develop Swing
application, use my CookSwing :)
http://cookxml.yuanheng.org/cookswing/
Contrary to common perceptions of XUL, CookSwing allows full / complete
tweaking with Java with supports for all layouts and all components
(including custom components). Also support non-Swing stuff. It is
very easy to use and extensible. There are essentially no drawbacks
using CookSwing.
For example, if your object has instance variable called inputBox1,
y |
|
g*****g
发帖数: 34805 | 34 1. Documentation, documentation... documentation?
I agree, documentation is much worse than spring and hibernate, but the
community is active and helpful
2. High learning curve
True only if you are coming from PHP/JSP background. A swing developer
would feel wicket natural.
3. Different... not better, but different
4x Java and 1/4 template, maybe true. But personally I prefer it.
Java is much easier to refactor and modularize. You can easily develop
a component, and reuse it in the next project. |
|
k***r
发帖数: 4260 | 35 All good points and I agree with most of them, except
"component based framework is the future". I'm not too
sure about that. It clearly has its own set of (major)
problems.
Statefulness comes at a price, though. Performance?
Since the server has to maintain a lot of things.
How are the sessions timed out?
Also, don't have have a concern about Wicket's search
engine de-optimization problem?
session
view. |
|
g*****g
发帖数: 34805 | 36 If URL is session dependent, it's not going to be search engine
friendly anyway right? Think of a forum that can't be accessed
without logging in first, search engine can't get nother without
logging in either.
Search engine can deal with restful resource only, and I don't
see why wicket has a problem with that. |
|
g*****g
发帖数: 34805 | 37
Component and tooling is always a big boost, think of why M$ had a huge
success on VB. You drag and drop and you program behavior, that's it.
You barely needs to work on the view. And how much time you've spent
on your JSP/Facelet/Velocity etc. these days? That's why I see wicket
is pointing the direction of future. With proper IDE support, you should
develop a backing model, you drag a widget to your view, you link the
model to your view by clicking mouse several times. And now you only
need t |
|
k***r
发帖数: 4260 | 38 My understanding (of that article) is that wicket URL is
session dependent. Many other systems' are not. Say, a forum
url could be http://site/forum/?id=2&post=2, if they use
hidden fields, cookies, etc.. These URLs are search
engine friendly. No session dependency.
Better yet, some frameworks allow you to construct URLs
anyway you want, say, http://site/shopping/shoes/sale,
and nothing else. These URLs are very SEO effective.
Intranet sites don't care as much but commercial sites do
care a lot. |
|
k***r
发帖数: 4260 | 39 Why did they have to throw JSP in there. I'd rather have
a simple HTML template like wicket's. |
|
k***r
发帖数: 4260 | 40 Interesting. I thought wicket only manages GUI state
with in-memory variables. Can't you take DB access in
your own hands?
"going
data |
|
F****n
发帖数: 3271 | 41 I don't believe Wicket or other similar GUI framework can cause big
performance problems. They must have done something stupid.
going
cached |
|
t*******e
发帖数: 684 | 42 The DetachedModel is a selling point of the technology, even it is not
mandatory. If state management in a project completely relies on the
detachedmodel concept, it will surely lead to a performance disaster.
Imaging all the data objects specific to a user are request scoped,
wicket automatically goes to the database to get a fresh copy on each request,
and clears them up exception for their primary keys after the response is served.
The technology does bite into the data access area. |
|
g*****g
发帖数: 34805 | 43 Wicket requires better OO skills, while action frameworks
may be easier for people with scripting and procedure languages
background. But anything can be a mess in the wrong hands.
about |
|
k***r
发帖数: 4260 | 44 你一直在用wicket，请问一段时间下来，有没有感觉这个过程中写的
components会有很多机会reuse，从而开发越来越快呢？还是只是
理论上如此，实际不太明显？想知道你的实践中的体会，谢谢！ |
|
g*****g
发帖数: 34805 | 45 可惜我没有太多机会用wicket，我们有一些legacy的project。
新的project又往往时间很紧，要让其他人学会并不容易。
但是从我做过的web项目来看，相似的component确实很多，如果
能好好包装一下的话，确实可以直接重用。从我看论坛上其他人
的说法来看，重用性不错。 |
|
k***r
发帖数: 4260 | 46 I see. Sounds like you are not using Wicket, which
renders components from server side? |
|
k***r
发帖数: 4260 | 47 I see. I wonder why multiple companies (that build icefaces and
richfaces, etc) choose to invest on a inferior framework while
not many are investing in a better one?
It looks like the components wicket has is not much different
from the ones it had 6 months or a year ago. I'm not sure
what hint we can get - not many people are using it? Or not
a lively community working and contributing back to the project?
I find it hard to justify investment in a nicer but poor (in
terms of number and quality |
|
k***r
发帖数: 4260 | 48 Thanks. A separate question, does wicket have support for
server push/comet? |
|
t*******e
发帖数: 684 | 49 Comparing the 3 web technologies, I have an interesting finding.
JSF has page layout, and component trees (in the form of JSF tags) both
declared in XHTML files.
Wicket maintains page layout in HTML, while component trees are defined in
Java classes. Component IDs in Java classes and the HTML placeholders have
to match.
Vaadin have both page layout and component trees defined in Java.
Obviously, Vaadin resembles SWING, in the sense that it is ajax event
driven, hides the HTML native code and req |
|
g*****g
发帖数: 34805 | 50 JSF is a disaster, neither coder friendly nor designer friendly.
I'd call it component model in Struts way.
Vaadin is exactly Swing. Coder friendly but not designer friendly.
But I can see it taking over once a rich
library is there. Building your own component is non-trivial, like
Swing.
Wicket is designer friendly but not as coder friendly. Easy to
create custom components. |
|
