Redian新闻
>
Anyone wants to talk about web frameworks?
avatar
Anyone wants to talk about web frameworks?# Java - 爪哇娇娃
g*g
1
I had used Struts before and mostly Spring MVC last couple of years.
I've been hearing wicket buzz these days and come across this blog today.
http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/
I think we are using exactly the same stack in the left, which is really
complicated and pain in the ass.
Biggest beefs are
1. Refactoring, changing all these webflow, spring mapping xml, JSPs,
Javascripts aren't productive. And you spend much time to recomplie and
d
avatar
t*e
2
Struts2(webork2), Spring MVC, JSF(Seam)有很多相似的地方。wicket有点背道而驰,
从declarative programming又退回到了programmatic development. Seam和JSF的设计
者都不太喜欢wicket。wicket的web pages是更干净了,但代价是更多的Java coding,
也不POJO. 顺便说一下,Swing开发本身就是个很不爽的活.
自己的经验感觉JSF的API最POJO和elegant,也最接近ASP.net.Strut2基本POJO,借鉴了
JSF的很多ideas,但不是component-oriented web framework,有些新的idea如RESTful
URLs很不错。Spring MVC API设计的较差,有些要developers遵守固定的naming
conventions, url patterns, 感觉比较乱,自由度低。目前我感觉最好的还是
Facelets, JSF, 和Spring Web Flow的组合,或者就是Facelets, JSF和Seam.
avatar
t*e
3
如果真的想用类似swing的开发方式,echo3也不错。Swing那么好的话,SUN也不会再提
出JavaFX了。
avatar
g*g
4
Thanks for the input.
What's the benefit of declarative navigation?
This part of XML is code, not really configuration that you want to
expose for admin. I don't understand why more Java code is no POJO,
isn't POJO plain old java objects? XML, JSF are not?
Change your xml file, redeploy and
restart your server is certainly not as productive as changing java code.
And you don't have to restart server if you don't change signature (in
debug mode).
Think of website as a desktop software. In rich cl

【在 t*******e 的大作中提到】
: Struts2(webork2), Spring MVC, JSF(Seam)有很多相似的地方。wicket有点背道而驰,
: 从declarative programming又退回到了programmatic development. Seam和JSF的设计
: 者都不太喜欢wicket。wicket的web pages是更干净了,但代价是更多的Java coding,
: 也不POJO. 顺便说一下,Swing开发本身就是个很不爽的活.
: 自己的经验感觉JSF的API最POJO和elegant,也最接近ASP.net.Strut2基本POJO,借鉴了
: JSF的很多ideas,但不是component-oriented web framework,有些新的idea如RESTful
: URLs很不错。Spring MVC API设计的较差,有些要developers遵守固定的naming
: conventions, url patterns, 感觉比较乱,自由度低。目前我感觉最好的还是
: Facelets, JSF, 和Spring Web Flow的组合,或者就是Facelets, JSF和Seam.

avatar
t*e
5
我指declarative programming,不是XML configuration。Object inheritance,
polymorphism使用在domain model上很好,business code可能还是越简单,越少
hierarchy才容易维护。EJB3和Spring都是这个宗旨,non-intrusive container,所以
EJB3和SpringBean都是POJO,理论上portability也好。不喜欢用XML的,可以用
annotations. Web framework是否是POJO可能不如business layer或DAO中那么重要。
本身web framework没有一个是perfect的,具体怎么用还是由requirement和developer
的knowledge base决定的。争论webframework在theserverside.com每次都是non-conclusive
discussions. 新的frameworks都不错,选择很大程度就是个个人喜好。
avatar
g*g
6
service层面上用POJO是不错的,本身就没有多少重用的问题,
可以group而不是extend。
web framework上,view component很多都是重复的,或者相近的,
比如一整个panel在另一个页面上重复出现是很常见的。无疑hierarchy
很有用。
我不是想争论哪个架构好,我是spring mvc用了很久,觉得这个东西
productivity不够好,JSF看着也一样复杂。觉得wicket的思想不错。

developer
conclusive

【在 t*******e 的大作中提到】
: 我指declarative programming,不是XML configuration。Object inheritance,
: polymorphism使用在domain model上很好,business code可能还是越简单,越少
: hierarchy才容易维护。EJB3和Spring都是这个宗旨,non-intrusive container,所以
: EJB3和SpringBean都是POJO,理论上portability也好。不喜欢用XML的,可以用
: annotations. Web framework是否是POJO可能不如business layer或DAO中那么重要。
: 本身web framework没有一个是perfect的,具体怎么用还是由requirement和developer
: 的knowledge base决定的。争论webframework在theserverside.com每次都是non-conclusive
: discussions. 新的frameworks都不错,选择很大程度就是个个人喜好。

avatar
t*e
7
不错,aggregation是比generalization容易维护。归根结底,设计好persistence
domain model和DAO的code是最重要的,整个系统的performance bottleneck都在那儿
了。以后这个application是否容易扩展也是看DAO layer。Web写的好就是锦上添花的
事。
avatar
g*g
8
web部分是应该很简单,但就因为快不起来,才让我重新考虑这个问题。
常见的比如pagination,比如flow,state在client/server来回转化带来很多麻烦。
包括spring web flow这样的东西,看着不错,其实是把很多if else
扔进了xml,并不符合pojo的思路。JSP EL, JSF EL也是一样的。

【在 t*******e 的大作中提到】
: 不错,aggregation是比generalization容易维护。归根结底,设计好persistence
: domain model和DAO的code是最重要的,整个系统的performance bottleneck都在那儿
: 了。以后这个application是否容易扩展也是看DAO layer。Web写的好就是锦上添花的
: 事。

avatar
t*e
9
你这么说我要再去仔细读读wicket的材料了。state的维护不管是seam还是spring web
flow都是靠新添的scope variables. Data binding一般都靠converter,的确是多余的
avatar
w*n
10
最近狂用javascript, server上返回的都是json,比以前简单多了. 不知道
HTML标准会怎么发展,感觉上JSF,FLEX之类的东西长远上来不看好。

【在 g*****g 的大作中提到】
: web部分是应该很简单,但就因为快不起来,才让我重新考虑这个问题。
: 常见的比如pagination,比如flow,state在client/server来回转化带来很多麻烦。
: 包括spring web flow这样的东西,看着不错,其实是把很多if else
: 扔进了xml,并不符合pojo的思路。JSP EL, JSF EL也是一样的。

avatar
t*e
11

javascript被称为browser的assembly language,不可能所有的web开发都是直接使用
assembly language。server side programming和javascript也不很match. GWT, Echo
, DWR, AJAX4JSF, DynamicFaces等等都是在javascript-ajax libraries之上搞个high
level,server-side APIs, 由server side Java code自动生成client side
javascript code. 不管HTML如何变化,server side的web framework都会不断发展并
跟上的。

【在 w******n 的大作中提到】
: 最近狂用javascript, server上返回的都是json,比以前简单多了. 不知道
: HTML标准会怎么发展,感觉上JSF,FLEX之类的东西长远上来不看好。

avatar
m*t
12
Replace sitemesh with jsf/facelets, and sprinkle some aop
here and there, and you pretty much have the front-end
architecture I'm working with these days.
1. Refactoring: it's a pain indeed - not only when refactoring,
but also when troubleshooting and apprehending.
My feeling though is that the answer lies in better IDE tooling
support and more rigorous testing, instead of moving most of
the stuff back into java code.
2. AJAX: I try to stay away from the "ajax wrappers" these days.
They are bas

【在 g*****g 的大作中提到】
: I had used Struts before and mostly Spring MVC last couple of years.
: I've been hearing wicket buzz these days and come across this blog today.
: http://ptrthomas.wordpress.com/2008/05/26/migrating-to-apache-wicket-presentation-slides/
: I think we are using exactly the same stack in the left, which is really
: complicated and pain in the ass.
: Biggest beefs are
: 1. Refactoring, changing all these webflow, spring mapping xml, JSPs,
: Javascripts aren't productive. And you spend much time to recomplie and
: d

avatar
g*g
13
Below are my 2c with limited knowledge on wicket.

IDE can help but definitely will never be as good as POJO. Java is
capable of handling most complex task, why not leave the complexities
there. Toying between js, jsf/jsp, xml and java certainly won't be
productive.
A language is meant to make simple things simple, and difficult things
possible.
Wicket makes it easy to write custom component in pure java, that probably
satisify 90% of common ajax needs, and doesn't stop you from
using your favor

【在 m******t 的大作中提到】
: Replace sitemesh with jsf/facelets, and sprinkle some aop
: here and there, and you pretty much have the front-end
: architecture I'm working with these days.
: 1. Refactoring: it's a pain indeed - not only when refactoring,
: but also when troubleshooting and apprehending.
: My feeling though is that the answer lies in better IDE tooling
: support and more rigorous testing, instead of moving most of
: the stuff back into java code.
: 2. AJAX: I try to stay away from the "ajax wrappers" these days.
: They are bas

avatar
m*t
14
I guess most of my comments from the previous post can be tied up
to one point: I absolutely hate having to rebuild and redeploy
the whole app just because I changed how one property should be
rendered. That's where php/RoR beats JEE hands down. And don't
tell me we don't need that in enterprise web apps - we can cut
down at least half of the heavy release cycles if we could drop
in one jsp file.
So you might also have guessed that I would disagree on "logic
in template is evil". 8-)
I believe i

【在 g*****g 的大作中提到】
: Below are my 2c with limited knowledge on wicket.
:
: IDE can help but definitely will never be as good as POJO. Java is
: capable of handling most complex task, why not leave the complexities
: there. Toying between js, jsf/jsp, xml and java certainly won't be
: productive.
: A language is meant to make simple things simple, and difficult things
: possible.
: Wicket makes it easy to write custom component in pure java, that probably
: satisify 90% of common ajax needs, and doesn't stop you from

avatar
g*g
15

I agree your redeploy argument 100%. And that's another point of
using Java as much as possible. If you don't change the signature of
classes/methods, you don't need to do anything at all in debug mode.
Can't say the same thing whenever you go to your nice navigation xml.
You can put on all scriptlet in jsp and it's like many people will
do php. But Java people go away from that for a good reason.
I would disagree with this. Our previous jsp would become crap in
dreamweaver. With wicket's way a

【在 m******t 的大作中提到】
: I guess most of my comments from the previous post can be tied up
: to one point: I absolutely hate having to rebuild and redeploy
: the whole app just because I changed how one property should be
: rendered. That's where php/RoR beats JEE hands down. And don't
: tell me we don't need that in enterprise web apps - we can cut
: down at least half of the heavy release cycles if we could drop
: in one jsp file.
: So you might also have guessed that I would disagree on "logic
: in template is evil". 8-)
: I believe i

avatar
m*t
16

But we don't run our app in debug mode in production, do we?
Also hotswapping doesn't always work even when the change doesn't
involve any API changes. For example, the previous version of
the class may be held somewhere (e.g. a reflection cache), and
the new version doesn't become effective, or worse only becomes
effective for some part of the app.
That's why hotswapping is only supported through the debug api.
Actually, we can. 8-)
You see, most of today's web frameworks don't support reloadi

【在 g*****g 的大作中提到】
:
: I agree your redeploy argument 100%. And that's another point of
: using Java as much as possible. If you don't change the signature of
: classes/methods, you don't need to do anything at all in debug mode.
: Can't say the same thing whenever you go to your nice navigation xml.
: You can put on all scriptlet in jsp and it's like many people will
: do php. But Java people go away from that for a good reason.
: I would disagree with this. Our previous jsp would become crap in
: dreamweaver. With wicket's way a

avatar
g*g
17

It's the frequent rebuild/restart in development that bother us developers.
You always ask deployment engineers to patch and restart, and we can
care less. We all run into the situation where a stupid typo in xml makes
you rebuild and restart, which can easily be eliminated if it's java code.
Designers are WYSIWYG guys, we use logic, they use eyes.
html easily give them a better idea than jsp.
The logic in the templates was associated with business logic
developers maintain, you probably have a

【在 m******t 的大作中提到】
:
: But we don't run our app in debug mode in production, do we?
: Also hotswapping doesn't always work even when the change doesn't
: involve any API changes. For example, the previous version of
: the class may be held somewhere (e.g. a reflection cache), and
: the new version doesn't become effective, or worse only becomes
: effective for some part of the app.
: That's why hotswapping is only supported through the debug api.
: Actually, we can. 8-)
: You see, most of today's web frameworks don't support reloadi

avatar
h*o
18
Swing: first generation of MVC with observer pattern.
Struts: second generation of MVC without observer pattern.
JSF: ? generation of MVC with observer pattern.
See life is a cycle. When struts first appeared, people hailed its power by
removing the notification process. Now JSF comes back as "Swing on the
server side".
Is it funny?
avatar
m*t
19

My point is exactly that we *shouldn't have to* keep
rebuilding and restarting to begin with, if we didn't keep
so much stuff in java code. Anywhere else we _can_ make it
reloadable, but not in the java code.
I showed you how it's not necessarily a better idea when
they don't see the possible branching. How can you possibly
design a page layout if you don't even know about all the
elements that could be rendered?
Well, this is where I said we probably had different
perceptions on what a page d

【在 g*****g 的大作中提到】
:
: It's the frequent rebuild/restart in development that bother us developers.
: You always ask deployment engineers to patch and restart, and we can
: care less. We all run into the situation where a stupid typo in xml makes
: you rebuild and restart, which can easily be eliminated if it's java code.
: Designers are WYSIWYG guys, we use logic, they use eyes.
: html easily give them a better idea than jsp.
: The logic in the templates was associated with business logic
: developers maintain, you probably have a

avatar
m*t
20

by
I thought it was pretty funny. Another example is,
we managed to externalize most of the "volatile
stuff" out to xml/properties files, and now we are
moving all the it back to hardcoded in java again.
The only difference is we now glorify the hardcoding,
and call it "annotating".

【在 h*********o 的大作中提到】
: Swing: first generation of MVC with observer pattern.
: Struts: second generation of MVC without observer pattern.
: JSF: ? generation of MVC with observer pattern.
: See life is a cycle. When struts first appeared, people hailed its power by
: removing the notification process. Now JSF comes back as "Swing on the
: server side".
: Is it funny?

avatar
g*g
21
Anything you won't change during the course of running is not hardcode.
Stuff like navigation XML is evil for me and certainly against OO.
Or should we call it string oriented programming?
Compare
return "login"
(And whole 9 yards of mapping xml here)
and
setResponsePage(LoginPage.class)
In case I need to rename Login to Welcome. The latter would be trivial
and the former would be the pain in the butt when you have tons of
references.
For spring, I would like to externalize any configuration int

【在 m******t 的大作中提到】
:
: by
: I thought it was pretty funny. Another example is,
: we managed to externalize most of the "volatile
: stuff" out to xml/properties files, and now we are
: moving all the it back to hardcoded in java again.
: The only difference is we now glorify the hardcoding,
: and call it "annotating".

avatar
m*t
22
Well, I obviously disagree, but we'd be beating the same
horse that you and I just beat to death. So like I said,
we'll just have to agree to disagree. 8-)

【在 g*****g 的大作中提到】
: Anything you won't change during the course of running is not hardcode.
: Stuff like navigation XML is evil for me and certainly against OO.
: Or should we call it string oriented programming?
: Compare
: return "login"
: (And whole 9 yards of mapping xml here)
: and
: setResponsePage(LoginPage.class)
: In case I need to rename Login to Welcome. The latter would be trivial
: and the former would be the pain in the butt when you have tons of

avatar
h*o
23
This thread reminds me another classic debate: store procedure or not.
convention based framework vs configuration based framework is just like
that. I guess 10 years later, there will still be somebodies debating on it
.
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。