A negative but well written article about Wicket - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Java - 爪哇娇娃

A negative but well written article about Wicket

A negative but well written article about Wicket# Java - 爪哇娇娃

k*r2009-04-30 07:04

1 楼

http://tietyt.blogspot.com/2009/03/top-8-reasons-i-dont-use-wicket.html
"I think it's the first really negative post I read
about Wicket, and I second Freddy, it's nicely written,
good points." - Remi
我看了一下，也觉得写的很好，很有道理的样子，至少从我的粗浅理解是这样。
Java web framework也不少了。在我看来真正好用的还没有 :(

g*g2009-04-30 07:04

2 楼

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 的大作中提到】

: http://tietyt.blogspot.com/2009/03/top-8-reasons-i-dont-use-wicket.html
: "I think it's the first really negative post I read
: about Wicket, and I second Freddy, it's nicely written,
: good points." - Remi
: 我看了一下，也觉得写的很好，很有道理的样子，至少从我的粗浅理解是这样。
: Java web framework也不少了。在我看来真正好用的还没有 :(

k*r2009-04-30 07:04

3 楼

Not sure if URL rewrite rules work for solving the
SEO problem, if that's what you meant. According to
the article, the URLs are session-dependent.
The SEO problem is a big downside if you ask me.
Have you tried Stripes? What's your take on that framework?

the

【在 g*****g 的大作中提到】

: 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.

g*g2009-04-30 07:04

4 楼

Stripes is the best action based framework, but I think component
based framework is the future. All action based frameworks have
difficulties in
1. Stateful wizard type applications, hacking hidden fields and session
isn't really fun.
2. Module reuse. JSP is not really great for reuse. JSP, with all the
EL in it, is against MVC pattern, EL is logic, and you have logic in view.
Other scripting templates share similar problems.

【在 k***r 的大作中提到】

: Not sure if URL rewrite rules work for solving the
: SEO problem, if that's what you meant. According to
: the article, the URLs are session-dependent.
: The SEO problem is a big downside if you ask me.
: Have you tried Stripes? What's your take on that framework?
:
: the

k*r2009-04-30 07:04

5 楼

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 的大作中提到】

:
: Stripes is the best action based framework, but I think component
: based framework is the future. All action based frameworks have
: difficulties in
: 1. Stateful wizard type applications, hacking hidden fields and session
: isn't really fun.
: 2. Module reuse. JSP is not really great for reuse. JSP, with all the
: EL in it, is against MVC pattern, EL is logic, and you have logic in view.
: Other scripting templates share similar problems.

g*g2009-04-30 07:04

6 楼

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.

【在 k***r 的大作中提到】

g*g2009-04-30 07:04

7 楼

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 的大作中提到】

: 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?
:

k*r2009-04-30 07:04

8 楼

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.

【在 g*****g 的大作中提到】

: 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*g2009-04-30 07:04

9 楼

http://site/forum/?id=2&post=2
This is not a session dependent URL, and since it's not,
it's easily bookamarkable.
Check this post for an example.
http://www.javalobby.org/java/forums/t68753.html
It's just an internal mapping to do forwarding, it can't be too hard.

【在 k***r 的大作中提到】

: 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*r2009-04-30 07:04

10 楼

This is one of the major things I'm not so sure about. I don't
think webapps is analogous to desktop apps. In a desktop
app, it's acceptable (encouraged) to use the standard Windows
widgets (buttons, menu, etc.) so components make a lot of
sense. In a webapp, it's the opposite. Each site is supposed
to come up with its own set of widgets with its own look&feel.
The site designer, and sometimes the administration, want
a site to work there way. A lot of times messing around with
CSS just won't cu

【在 g*****g 的大作中提到】

: http://site/forum/?id=2&post=2
: This is not a session dependent URL, and since it's not,
: it's easily bookamarkable.
: Check this post for an example.
: http://www.javalobby.org/java/forums/t68753.html
: It's just an internal mapping to do forwarding, it can't be too hard.

k*r2009-04-30 07:04

11 楼

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 的大作中提到】

g*g2009-04-30 07:04

12 楼

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

【在 k***r 的大作中提到】

: 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*g2009-04-30 07:04

13 楼

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

【在 k***r 的大作中提到】

: This is one of the major things I'm not so sure about. I don't
: think webapps is analogous to desktop apps. In a desktop
: app, it's acceptable (encouraged) to use the standard Windows
: widgets (buttons, menu, etc.) so components make a lot of
: sense. In a webapp, it's the opposite. Each site is supposed
: to come up with its own set of widgets with its own look&feel.
: The site designer, and sometimes the administration, want
: a site to work there way. A lot of times messing around with
: CSS just won't cu

k*r2009-04-30 07:04

14 楼

Why did they have to throw JSP in there. I'd rather have
a simple HTML template like wicket's.

【在 g*****g 的大作中提到】

:
: 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

u*r2009-04-30 07:04

15 楼

k*r2009-04-30 07:04

16 楼

Is JSP popular again? I thought everybody was moving away
from it.

【在 g*****g 的大作中提到】

t*e2009-04-30 07:04

17 楼

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*g2009-04-30 07:04

18 楼

No, but JSP is still most popular view technology.

【在 k***r 的大作中提到】

: Is JSP popular again? I thought everybody was moving away
: from it.

k*r2009-04-30 07:04

19 楼

Interesting. I thought wicket only manages GUI state
with in-memory variables. Can't you take DB access in
your own hands?

"going
data

【在 t*******e 的大作中提到】

: 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,

F*n2009-04-30 07:04

20 楼

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 的大作中提到】

t*e2009-04-30 07:04

21 楼

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.

【在 F****n 的大作中提到】

: I don't believe Wicket or other similar GUI framework can cause big
: performance problems. They must have done something stupid.
:
: going
: cached

g*g2009-04-30 07:04

22 楼

This doesn't neccesarily cause performance issue. From web tier point
of view, you want to get a fresh copy of DB object in every request,
that's a valid requirement in most applications, and caching shouldn't
be done in web tier.
You can always configure caching on DTO between either web/service layers,
or service/persistence layers. And these objects become application scope
immediately. Also these caching can be distributed so clustering is not a
problem. When you are using it with ORM, it ca

【在 t*******e 的大作中提到】

: 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.

t*e2009-04-30 07:04

23 楼

Ultimately, how to make use of the technology is up to developers savvy.
It could be a pitfall for inexperienced developers.

layers,
scope
not a
well.
viewed
items,

【在 g*****g 的大作中提到】

: This doesn't neccesarily cause performance issue. From web tier point
: of view, you want to get a fresh copy of DB object in every request,
: that's a valid requirement in most applications, and caching shouldn't
: be done in web tier.
: You can always configure caching on DTO between either web/service layers,
: or service/persistence layers. And these objects become application scope
: immediately. Also these caching can be distributed so clustering is not a
: problem. When you are using it with ORM, it ca

F*n2009-04-30 07:04

24 楼

It's like use hibernate classes as in-memory Collections and complain about
performance. That's the stupidity I am talking about.

request,
served.

【在 t*******e 的大作中提到】

g*g2009-04-30 07:04

25 楼

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

【在 F****n 的大作中提到】

: It's like use hibernate classes as in-memory Collections and complain about
: performance. That's the stupidity I am talking about.
:
: request,
: served.