g*****g
发帖数: 34805 | 1 我老给你指点一下吧。你应该用Vaadin。GWT的widget都在，写起来可是容易太多了。
纯java，就跟写swing差不多。
an
rendering
energy. |
|
g*****g
发帖数: 34805 | 2 Vaadin is much simpler though SmartGWT probably has more widgets.
I don't know that well about charting widgets, but you can check
yourself. |
|
g*****g
发帖数: 34805 | 3 Maybe you should get yourself educated and stop being so ignorant. This is
how RIA is defined on wiki.
"A Rich Internet Application (RIA) is a Web application that has many of the
characteristics of desktop application software, typically delivered by way
of a site-specific browser, a browser plug-in, an independent sandbox,
extensive use of JavaScript, or a virtual machine."
And some technologies, like GWT, ExtJS and Vaadin are mentioned on that page
, which all render pure html/js in the brows... 阅读全帖 |
|
|
k***r
发帖数: 4260 | 5 嗯。偶的初衷是一个framework能做网站和RIA。现在发现RIA framework
好像大部分有SEO问题，除了Click。如果不用Click，可能要RIA用一个，
普通网站用一个。
现在偶的倾向是RIA用Vaadin，网页风格的还没有确定。
Echo2和Echo3 style是proprietary的，不理想。 |
|
o**1
发帖数: 6383 | 6 RIA 还有很多吧
ZK, Vaadin, click 等等的
选择忒多了也是麻烦
outdated
mature |
|
|
F****n
发帖数: 3271 | 8 Ironically, some people have been working hard to give Swing a Web-like feel
,so their applet/application will look familiar to browser-love people. Who
want a Web-page to be like a dumb platform GUI? It scares people away:) |
|
k****u
发帖数: 133 | 9 Ironically, the desktop-like web apps don't scare people away at all, in the
contrary, people are seeking hard for the high interactiveness of the
desktop GUI on today's RIAs. And that's exactly where major RIA frameworks like GWT/
Flex are heading towards.
feel
Who |
|
g*****g
发帖数: 34805 | 10 Not necessarily, Gmail is more desktop like than Web-like, but popular
nonetheless.
feel
Who |
|
k***r
发帖数: 4260 | 11 Just to add to the problem list: SEO hostile. |
|
k***r
发帖数: 4260 | 12 yeah. I remember it uses the same URL ...
frameworks
problem, |
|
b******y
发帖数: 1684 | 13 server side framework会不会太chatty呢？ |
|
k****u
发帖数: 133 | 14
What do you mean by "chatty"? Are you referring to too much data exchange
between client and server? It's all AJAX, so the amount of data exchange
between client and server is much less than traditional server side
framework, like JSP/Servlet. However, it may still require more data
exchange than pure client side RIA frameworks. It's a trade-off: that extra
data exchange is the price you pay, but you get all the advantages of server
side frameworks - security, easy to program, simplified logic, |
|
b******y
发帖数: 1684 | 15 那怎么避免DTO pattern呢？
extra
server |
|
|
b******y
发帖数: 1684 | 17 ft, 怎么样才能既不用DTO，又不会太chatty呢？
i suppose 都在server上 = chatty |
|
g*****g
发帖数: 34805 | 18 Of course not, as long as it uses ajax for frontend.
Only partial page is updated. Actually, it uses GWT
as front end, so the loading part may be slower than GWT,
after loaded, it should be as fast as GWT. |
|
t*******e
发帖数: 684 | 19 Strongly agreed.
To achieve better usability, rich user experience, and probably
productivity, RIA is seemingly a better choice than conventional HTML
development approaches. In portal environments, portlets developed on top
of RIA technologies are more adaptable to the themes/skins of portal
pages. Compromising look and feel is sometimes necessary.
professional |
|
t*******e
发帖数: 684 | 20 Use JPA/Hibernate conversation along with Optimistic locking to avoid DTO
and detached entity state. |
|
t*******e
发帖数: 684 | 21 The sample code looks so close to Wicket and Swing. The advantage it claims
is against declarative UI programming, the direction GWT has steered toward.
I wonder how it is going to accommodate the new release of GWT. ZK is still
more advanced in terms of its POJO programming style and declarative UI. |
|
F****n
发帖数: 3271 | 22 I have used RIA for a while, and you know what, I think the best RIA is
Swing Applet. I won't do / recommend ajax-based RIA (unless it is really
simple, e.g. as simple supplements to a Web page) and will only do it when
asked. |
|
g*****g
发帖数: 34805 | 23 If JVM runtime is installed as much as flash or .Net, and
the footprint is 2MB and loads instantly. It'll be much more
used than right now. Too bad that's not the case, even JavaFX
doesn't fix it. |
|
F****n
发帖数: 3271 | 24 Even that it is still better than ajax-based RIA. |
|
g*****g
发帖数: 34805 | 25 Can't agree with that. Not one applet is as popular as gmail. |
|
m****r
发帖数: 6639 | 26 really? how about the "do you want to send the exception to microsoft?"
applet?
i use that one all the time. |
|
g*****g
发帖数: 34805 | 27 Yes, it's more popular, but not a java applet. |
|
F****n
发帖数: 3271 | 28 Gmail is an excellent example that an very simple RIA can work. You don't
need a framework to build Gmail. |
|
b******y
发帖数: 9224 | 29 I still like a clean separation of the web/html from the underlying model
and controller.
I think the reason the industry moved away from client/server to web, is
because web is simpler, html people could do html coding and server guys
could do server stuff. They could also work in parallel. But I don't see how
GWT could be suitable for that.
Anyway, I don't have much experience with GWT, but just my personal thoughts
... |
|
g*****g
发帖数: 34805 | 30 The client is getting thinner since it's much cheaper to upgrade
and maintain when all stuff is on server side. Plus no worry on
virus.
how
thoughts |
|
g*****g
发帖数: 34805 | 31 用vaadin把我swing版的发包子机改写，确实很方便也很像swing，
一天不到改完了。
想放到google apps engine上，发现HtmlUnit GAE里用不了，有些类
不让用，那帮人也在讨论这个，看似只能等几个月再看了。 |
|
o**1
发帖数: 6383 | 32 有一个问题，上传中文名字的文件的时候，receiver拿到都是乱码，iso-8859-1编码的
好像。
哪位知道如何解决这个问题？
thx |
|
g*****g
发帖数: 34805 | 33 当年碰到过中文名上传问题，印象中IE和FF上传的处理不一样，
你可以换个浏览器试试看。然后google中文的网页，估计要根据
user-agent 编码。 |
|
m******t
发帖数: 2416 | 34 The out of box experience was impressive. I like the easy and
straightforward paradigm, which makes it possible to spend
most of the time actually implementing features, instead of
learning the tool. And the ability to implement logic in
full java capabilities (vs. GWT's watered-down subset) is
incredibly satisfying.
The big concern though is that the price we pay for all the
good things above is to do everything on the server. The UI
isn't going to be very snappy due to network latency. No
matt |
|
g*****g
发帖数: 34805 | 35 It's not going to be as fast as pure client side framework,
and it never will.
But you are still only updating a portion of the page at
a time. So called AJAX. The generation of that portion is
done on server side, I think it's going to be faster than
request-based frameworks where the entire page is sent over
the wire.
The other drawback would be memory consumption in the session.
Overall it's still very Swing and certainly fits a lot of
projects. |
|
m******t
发帖数: 2416 | 36 Well, from a user's point of view, the response time of
a mouse click or key stroke has little to do with the amount
of page updates. That's _especially_ true for ajax
applications because the user is already used to incredibly
fast partial page updates.
I click on a check box, if it takes more than maybe
a second for that optional field to show up, that's not
feeling very responsive. If the user and the server are
on different coasts or continents, the network latency
alone is going to be half |
|
t*******e
发帖数: 684 | 37 JSF core是个HTML centric的framework, 应对accessibility508没问题。Spring Web
Flow和Wicket有AJAX fallback, 也可以。ICEFaces就是个披着羊皮(JSF)的狼(RIA),
没有Javascript完全不干活。Vaadin和GWT没javascript就更不行了。但是RIA都有
built-in themes, 没designer也能干活。HTML centric的frameworks都号称designer
friendly, 实际上离开HTML designer根本玩不转。选个framework实在痛苦。 |
|
t*******e
发帖数: 684 | 38 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. |
|
m******t
发帖数: 2416 | 39
That might be true not because of any technical merits but simply because it
carries a JSR badge. |
|
g*****g
发帖数: 34805 | 40 EJB2.x had one and it didn't go anywhere.
it |
|
t*******e
发帖数: 684 | 41 persistence programming比较特别。component有自己的data buffer，也可以直接
bind persistent entities, 但是entitymanager的scope不如传统的httprequest,
response容易界定. OpenEntityManagerInView估计无法使用. 说到底，Hibernate/JPA是为
传统Http request response lifecycle设计的。 |
|
t*******e
发帖数: 684 | 42 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
发帖数: 2416 | 43
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******y
发帖数: 9224 | 44
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*******e
发帖数: 684 | 45 你确信是因为JSF才crash的，不是后台的问题？
and |
|
m******t
发帖数: 2416 | 46
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
发帖数: 684 | 47 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
发帖数: 2416 | 48 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
发帖数: 684 | 49 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
发帖数: 2416 | 50
"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 |
|
