JSF, Wicket, and Vaadin - 未名空间MITBBS历史存档

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

Redian新闻

>未名空间

>Java - 爪哇娇娃

JSF, Wicket, and Vaadin

JSF, Wicket, and Vaadin# Java - 爪哇娇娃

t*e2010-06-22 07:06

1 楼

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*g2010-06-22 07:06

2 楼

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.

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

: 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

t*e2010-06-22 07:06

3 楼

I knew you would show up on this topic. Given the improvements made in the
2.0 release, JSF is actually pretty neat. It has and will outlive most of
other frameworks.

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

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

m*t2010-06-22 07:06

4 楼

That might be true not because of any technical merits but simply because it
carries a JSR badge.

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

: I knew you would show up on this topic. Given the improvements made in the
: 2.0 release, JSF is actually pretty neat. It has and will outlive most of
: other frameworks.

g*g2010-06-22 07:06

5 楼

EJB2.x had one and it didn't go anywhere.

it

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

:
: That might be true not because of any technical merits but simply because it
: carries a JSR badge.

o*12010-06-22 07:06

6 楼

vaadin 点个 dropdown 什么的，都需要跑 server 一趟，这一点很不爽。

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

t*e2010-06-22 07:06

7 楼

persistence programming比较特别。component有自己的data buffer，也可以直接
bind persistent entities, 但是entitymanager的scope不如传统的httprequest,
response容易界定. OpenEntityManagerInView估计无法使用. 说到底，Hibernate/JPA是为
传统Http request response lifecycle设计的。

【在 o**1 的大作中提到】

: vaadin 点个 dropdown 什么的，都需要跑 server 一趟，这一点很不爽。

m*t2010-06-22 07:06

8 楼

JPA是为
You could still implement the same "open in view" pattern
using vaadin's transaction listener. The difficulty lies in that it's hard
to tell which requests will eventually need database access, so you
might end up opening more sessions than necessary.
There are also some issues related to previously detached objects due to
vaadin passing objects across requests.

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

: persistence programming比较特别。component有自己的data buffer，也可以直接
: bind persistent entities, 但是entitymanager的scope不如传统的httprequest,
: response容易界定. OpenEntityManagerInView估计无法使用. 说到底，Hibernate/JPA是为
: 传统Http request response lifecycle设计的。

t*e2010-06-22 07:06

9 楼

The question is how to define a view in a single page application?
Perhaps, the concept of flow is more appropriate than view in RIA.
Considering a flow as a specific use case in the application, we can
adhere to the same extended persistence context object during the course
of the flow. Effectively, this approach eliminates detached entities and
the lazy loading exception. The persistence context object will be closed
automatically when a user chooses to leave the current flow/use case.

hard

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

:
: JPA是为
: You could still implement the same "open in view" pattern
: using vaadin's transaction listener. The difficulty lies in that it's hard
: to tell which requests will eventually need database access, so you
: might end up opening more sessions than necessary.
: There are also some issues related to previously detached objects due to
: vaadin passing objects across requests.

m*t2010-06-22 07:06

10 楼

The "view" here really should have been "request/response cycle".
The pattern is called what it's called only because of historic reasons.
From the server's perspective, whether an application consists of
1 or 10 pages is no longer relevant. What's relevant is there are still
many request/response cycles. The essence of the pattern is just to
ensure that throughout each cycle there is one and only one hibernate
session.
I'm sure that'll work, except that there is always some potential risk
from

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

: The question is how to define a view in a single page application?
: Perhaps, the concept of flow is more appropriate than view in RIA.
: Considering a flow as a specific use case in the application, we can
: adhere to the same extended persistence context object during the course
: of the flow. Effectively, this approach eliminates detached entities and
: the lazy loading exception. The persistence context object will be closed
: automatically when a user chooses to leave the current flow/use case.
:
: hard

t*e2010-06-22 07:06

11 楼

One concern is on the granularity of the database operations, more
specifically, updates. Secondly, those short lived Hibernate session
objects will lead to many detached entities, if they are ever cached.
Read-only access would be fine though. Let me finish my reading on
Vaadin, and come back to this discussion.

reasons.
still
user

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

:
: The "view" here really should have been "request/response cycle".
: The pattern is called what it's called only because of historic reasons.
: From the server's perspective, whether an application consists of
: 1 or 10 pages is no longer relevant. What's relevant is there are still
: many request/response cycles. The essence of the pattern is just to
: ensure that throughout each cycle there is one and only one hibernate
: session.
: I'm sure that'll work, except that there is always some potential risk
: from

b*y2010-06-22 07:06

12 楼

Haha, I love your comment.
We had a JSF based application before, and it crashed from time to time and
memory intensive.
We switched simple Spring + Velocity template based architecture, now it
works like a charm

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

t*e2010-06-22 07:06

13 楼

你确信是因为JSF才crash的，不是后台的问题？

and

【在 b******y 的大作中提到】

:
: Haha, I love your comment.
: We had a JSF based application before, and it crashed from time to time and
: memory intensive.
: We switched simple Spring + Velocity template based architecture, now it
: works like a charm

t*e2010-06-22 07:06

14 楼

Vaadin的书没有提到persistence。有个wiki文章介绍了一下。基本上是EJB1/2里面的
value object(DTO) pattern，把detached entities当value object来用了。update
entity用merge()。实际上，persistent entity是自动synchronize database的。那个
TransactionListener就是个非常简单的filter,没什么大的帮助。Detached entitie都存在
Http Session里。还有就是Data Model API比较麻烦。对Hibernate的支持太弱了。个人感觉如
果整合seam page flow可能比较好。不过在此之前，对后台hibernate的applications, 真不好
用。

m*t2010-06-22 07:06

15 楼

You lost me here - your domain objects don't suddenly
become DTO's just because they are passed from one request to another.
Whatever domain behaviors they have are still there.

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

: Vaadin的书没有提到persistence。有个wiki文章介绍了一下。基本上是EJB1/2里面的
: value object(DTO) pattern，把detached entities当value object来用了。update
: entity用merge()。实际上，persistent entity是自动synchronize database的。那个
: TransactionListener就是个非常简单的filter,没什么大的帮助。Detached entitie都存在
: Http Session里。还有就是Data Model API比较麻烦。对Hibernate的支持太弱了。个人感觉如
: 果整合seam page flow可能比较好。不过在此之前，对后台hibernate的applications, 真不好
: 用。

t*e2010-06-22 07:06

16 楼

Entities are designed to work under the persistent state, where they
automatically synchronize their values with the database rows in the
scope of read-write transactions. Note the nature of Hibernate session
is an in-memory database mirroring a portion of the physical database.
In OpenSessionInView, entities passed from one request to anther become
detached. Detached entities are effectively DTO/Value objects, as they
are no longer managed by the in-memory database.
What makes SEAM and Spring

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

:
: You lost me here - your domain objects don't suddenly
: become DTO's just because they are passed from one request to another.
: Whatever domain behaviors they have are still there.

m*t2010-06-22 07:06

17 楼

I see what you mean now. I don't know though... IMO detached entities are
still quite different from mere DTO's, in that you still need to treat them
with some respect :) because at some point in the near future you are
going to reattach them and merge them back into the db.

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

: Entities are designed to work under the persistent state, where they
: automatically synchronize their values with the database rows in the
: scope of read-write transactions. Note the nature of Hibernate session
: is an in-memory database mirroring a portion of the physical database.
: In OpenSessionInView, entities passed from one request to anther become
: detached. Detached entities are effectively DTO/Value objects, as they
: are no longer managed by the in-memory database.
: What makes SEAM and Spring

t*e2010-06-22 07:06

18 楼

Calling merge is fine as long as optimistic locking is well taken care of.
Apart from the detached entity state, transaction granularity is the other
concern I mentioned above. Scoping database write transactions to the
level of ajax operations defeats the purpose of having database
transactions, and can easily overload the database.

are
them

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

: I see what you mean now. I don't know though... IMO detached entities are
: still quite different from mere DTO's, in that you still need to treat them
: with some respect :) because at some point in the near future you are
: going to reattach them and merge them back into the db.

m*t2010-06-22 07:06

19 楼

"Um... ok... but..." on both counts:
1. The purpose of db transactions is CRUD, which is still there regardless
of whether the transaction is done by an ajax request or a regular form
submission.
2. OpenSessionInView only opens a hibernate session, not a transaction, upon
a request. Granted that might very well overload the _app_server_, but that'
s
a different issue. A transaction, a R/W one anyway, would still be initiated
when something actually needs to be written to the db. Again I can har

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

: Calling merge is fine as long as optimistic locking is well taken care of.
: Apart from the detached entity state, transaction granularity is the other
: concern I mentioned above. Scoping database write transactions to the
: level of ajax operations defeats the purpose of having database
: transactions, and can easily overload the database.
:
: are
: them

t*e2010-06-22 07:06

20 楼

I don't agree on the your first point. Transaction is for data
integrity. Revisiting the XA protocol may help us to get some insights
on transactions. You miss my point on Hibernate conversation again.
Hibernate session is a data cache, more precisely, an OODB resembling a
tiny portion of the relational database. Data changes don't have to be
synchronized to the database on every user request, especially for ajax
requests (think about transaction and database performance). Assuming a
Hibernate l

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

:
: "Um... ok... but..." on both counts:
: 1. The purpose of db transactions is CRUD, which is still there regardless
: of whether the transaction is done by an ajax request or a regular form
: submission.
: 2. OpenSessionInView only opens a hibernate session, not a transaction, upon
: a request. Granted that might very well overload the _app_server_, but that'
: s
: a different issue. A transaction, a R/W one anyway, would still be initiated
: when something actually needs to be written to the db. Again I can har

t*e2010-06-22 07:06

21 楼

Persistence programming is the most versatile and advance subject in server
side programming. Hibernate is innovate but very complex. It takes years to
have the inside out.

b*y2010-06-22 07:06

22 楼

我们那个时候用的JSF好像是IBM的implemenation, 有bug. 现在的可能好多了，不过，
后来用velocity后就没有再用jsf了。

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

: 你确信是因为JSF才crash的，不是后台的问题？
:
: and

t*e2010-06-22 07:06

23 楼

Haven't heard any IBM implementation of JSF. The ones I know of are
Mojarra
(SUN RI) and MyFaces.

【在 b******y 的大作中提到】

:
: 我们那个时候用的JSF好像是IBM的implemenation, 有bug. 现在的可能好多了，不过，
: 后来用velocity后就没有再用jsf了。

u*s2010-06-22 07:06

24 楼

IBM Java bug 太多，更新也没有Sun Java及时

【在 b******y 的大作中提到】

:
: 我们那个时候用的JSF好像是IBM的implemenation, 有bug. 现在的可能好多了，不过，
: 后来用velocity后就没有再用jsf了。

m*t2010-06-22 07:06

25 楼

Honestly by now I am completely lost as to what exactly we are debating
about. :)

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

: I don't agree on the your first point. Transaction is for data
: integrity. Revisiting the XA protocol may help us to get some insights
: on transactions. You miss my point on Hibernate conversation again.
: Hibernate session is a data cache, more precisely, an OODB resembling a
: tiny portion of the relational database. Data changes don't have to be
: synchronized to the database on every user request, especially for ajax
: requests (think about transaction and database performance). Assuming a
: Hibernate l

b*t2010-06-22 07:06

26 楼

i never understand why IBM try to be smart ass to reinvent the wheel.

【在 u****s 的大作中提到】

: IBM Java bug 太多，更新也没有Sun Java及时

u*s2010-06-22 07:06

27 楼

大部分直接用的Sun的源码，自己改了一些，加了一些。但很多都改坏了。
IBM大部分的software engineers都是垃圾。

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

: i never understand why IBM try to be smart ass to reinvent the wheel.

q*u2010-06-22 07:06

28 楼

........

大部分直接用的Sun的源码，自己改了一些，加了一些。但很多都改坏了。
IBM大部分的software engineers都是垃圾。

【在 u****s 的大作中提到】

: 大部分直接用的Sun的源码，自己改了一些，加了一些。但很多都改坏了。
: IBM大部分的software engineers都是垃圾。

t*e2010-06-22 07:06

29 楼

BEA Jrockit还是很不错的。

s*e2010-06-22 07:06

30 楼

Considering the history of Domain Object and VO (some people like to mix it
with DTO, actually they are not the same thing, at least they were not
invented for the same purpose), I will say that I have to agree to magicfat.
One of initial selling point was that you can detached DO and pass it around
among the tier. The arguments for doing this was that you could eliminate
multiple copies of same(similiar) objects among the tiers, this might make
the code less error-prone and no need for synching

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

: Honestly by now I am completely lost as to what exactly we are debating
: about. :)

t*e2010-06-22 07:06

31 楼

Obviously you have a lot of insights on persistence programming. Without
auto-dirty checking, merging a good number of detached entities is very
costly from database perspective.

mix it
magicfat.
around
eliminate
make
many
among the
some

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

: Considering the history of Domain Object and VO (some people like to mix it
: with DTO, actually they are not the same thing, at least they were not
: invented for the same purpose), I will say that I have to agree to magicfat.
: One of initial selling point was that you can detached DO and pass it around
: among the tier. The arguments for doing this was that you could eliminate
: multiple copies of same(similiar) objects among the tiers, this might make
: the code less error-prone and no need for synching

m*u2010-06-22 07:06

32 楼

I am learning JSF now. I have some background on J2EE (hibernate, Spring)
and J2SE, felt front end programming is quite different. Not in a position
to comment on the JSF technology, will do it once I have more experience.

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