s****s
发帖数: 628 | |
e*****t
发帖数: 1005 | 2 servlet is the underlying technology and you'd better get a grasp of it. But
you rarely need to write your own servlet.
JSF is something built on top of servlet, which is more important than servl
et itself. If you want to work with a JavaEE webapplication. You probably wa
nt to pay more attention to JSF.
【在 s****s 的大作中提到】
: 这俩有什么区别? 是不是只学一个就够了.
|
s****s
发帖数: 628 | 3 谢谢.
But
servl
wa
【在 e*****t 的大作中提到】
: servlet is the underlying technology and you'd better get a grasp of it. But
: you rarely need to write your own servlet.
: JSF is something built on top of servlet, which is more important than servl
: et itself. If you want to work with a JavaEE webapplication. You probably wa
: nt to pay more attention to JSF.
|
c*********e
发帖数: 16335 | 4 jsf据说会代替jsp.
【在 s****s 的大作中提到】
: 这俩有什么区别? 是不是只学一个就够了.
|
e*****t
发帖数: 1005 | 5 yes, let's oracle's plan and does make sense.
it's more elegant and has better support of states and objects. it's a MVC f
ramework from the beginning.
【在 c*********e 的大作中提到】
: jsf据说会代替jsp.
|
g*****g
发帖数: 34805 | |
w**z
发帖数: 8232 | 7 both are outdated technology, it is all JS now.
【在 c*********e 的大作中提到】
: jsf据说会代替jsp.
|
b******y
发帖数: 9224 | 8
同意。当年我加入公司的时候，前lead developer用IBM的JSF开发了个内部的产品管理
系统。结果，总是30分钟不到就内存溢出了。这个也许是IBM的JSF实现的不好，也许是
他编程的时候用的node太多了？Anyway.
我的感觉，JSF是肉包铁，Java servlet是铁包肉。是不是有点形象的比喻? 呵呵
如果我没记错的话，JSF在内存里生成了对应的html page的tree structure，所以，占
内存大。而且，designer很难插手做前台?
jsp还好。不过，我们都用的是Velocity template engine. 简单，速度快。我也自己
编写过一个类似的java template engine, 感觉这东西比jsp更加MVC.
【在 g*****g 的大作中提到】
: jsf is going nowhere.
|
z***s
发帖数: 3241 | 9 有种说法是理解了servlet才真正理解什么是j2ee？？ |
z****e
发帖数: 54598 | 10 servlet有j2ee的一半都算抬举servlet了
【在 z***s 的大作中提到】
: 有种说法是理解了servlet才真正理解什么是j2ee？？
|
|
|
o**1
发帖数: 6383 | 11 JSF 现在跟当年不一样了，已经算不错的front-end技术了。
尤其是跟CDI的结合，挺方便的。又是standard。
如果你是在 java ee 上做东西 jsf 是一个选择。
如果你只在web container上做东西，有很多别的选择。jsf反而显的啰嗦。
servlet我觉得很重要，把它底层如果工作的搞清楚对自己技术的提高很有帮助。
很多framework都是在这一套上面做的。
【在 s****s 的大作中提到】
: 这俩有什么区别? 是不是只学一个就够了.
|
o**1
发帖数: 6383 | 12 jsf 还在坚持，也改变了很多，但是还是用的人不多。
jsp就是所有 container都支持，不用什么额外的 jar.
最好的 template engine 是 thymeleaf, 几乎能想到的方便的地方它都有。
也非常适合美工和程序员合作。
【在 b******y 的大作中提到】
:
: 同意。当年我加入公司的时候，前lead developer用IBM的JSF开发了个内部的产品管理
: 系统。结果，总是30分钟不到就内存溢出了。这个也许是IBM的JSF实现的不好，也许是
: 他编程的时候用的node太多了？Anyway.
: 我的感觉，JSF是肉包铁，Java servlet是铁包肉。是不是有点形象的比喻? 呵呵
: 如果我没记错的话，JSF在内存里生成了对应的html page的tree structure，所以，占
: 内存大。而且，designer很难插手做前台?
: jsp还好。不过，我们都用的是Velocity template engine. 简单，速度快。我也自己
: 编写过一个类似的java template engine, 感觉这东西比jsp更加MVC.
|
t*******e
发帖数: 684 | 13 现在没人用plain JSF，都有用RIA libs, 像primefaces之类，有javascript
abstraction，开发效率非常高。没有component model+js abstraction，让你几个月
时间开发上百页的RIA app，无法想象。healthcare为例，会有很长的workflow，复杂
的forms。
nodejs适合有js背景的人用，局限也不少。
关于web framework的争论一直都在，很多年前关于wicket就在本版讨论的很火爆。不
知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
定使用的技术。 |
o**1
发帖数: 6383 | 14 wicket估计没什么戏。
这种把应该前台做的工作拿到后台去做的web framework都是把简单问题复杂化。
GWT 也是这个样子，现在已经下坡路的厉害。
【在 t*******e 的大作中提到】
: 现在没人用plain JSF，都有用RIA libs, 像primefaces之类，有javascript
: abstraction，开发效率非常高。没有component model+js abstraction，让你几个月
: 时间开发上百页的RIA app，无法想象。healthcare为例，会有很长的workflow，复杂
: 的forms。
: nodejs适合有js背景的人用，局限也不少。
: 关于web framework的争论一直都在，很多年前关于wicket就在本版讨论的很火爆。不
: 知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
: 定使用的技术。
|
b******y
发帖数: 9224 | 15
谢谢。看了一下thymeleaf, 不错。但有个问题是, velocity可以生成email template,
html或者text版本的。但好像thymeleaf只能做xml/html的?
【在 o**1 的大作中提到】
: jsf 还在坚持，也改变了很多，但是还是用的人不多。
: jsp就是所有 container都支持，不用什么额外的 jar.
: 最好的 template engine 是 thymeleaf, 几乎能想到的方便的地方它都有。
: 也非常适合美工和程序员合作。
|
g*****g
发帖数: 34805 | 16 server side component based is not going anywhere. For two major issues.
1. Poor separation of backend and frontend personnel. web pages tend to be
more flashy than traditional desktop UI. While components are handy, it's
painful to customize CSS, and creating new components is difficult too.
2. Performance, this takes lots of memory and it's not suitable for websites
that can serve 10s of millions of users. It's probably an OK choice for
internal websites.
With html5/JS components getting stronger everyday, the writing is on the
wall. |
e*****t
发帖数: 1005 | 17 I agree with this.
By using js component based frameworks, front end UI developers can easily p
rototype UI desgins without much backend interaction.
Our UI developers do their prototyping or some bug fixing on some kind of mo
ck server (tomcat based). They hate to bring up the full application (jboss)
, which may take up to 15 mins to start, not to mention the data setup.
On the other hand, JSP/JSFs are used to server the http requests. They serve
r the pages, and it works well for big page level components. But I suppose
that's not the original purpose of JSF.
websites
【在 g*****g 的大作中提到】
: server side component based is not going anywhere. For two major issues.
: 1. Poor separation of backend and frontend personnel. web pages tend to be
: more flashy than traditional desktop UI. While components are handy, it's
: painful to customize CSS, and creating new components is difficult too.
: 2. Performance, this takes lots of memory and it's not suitable for websites
: that can serve 10s of millions of users. It's probably an OK choice for
: internal websites.
: With html5/JS components getting stronger everyday, the writing is on the
: wall.
|
t*******e
发帖数: 684 | 18 Not the first time you made such a statement. The truth is, component model
is an abstraction layer hiding programming complexity in HTML/JS. Given that
UI components are managed and enriched constantly by software vendors, the
same set of components rendering HTML today can generate HTML5 tomorrow. A
component-based website can be upgraded to HTML5 with new features almost
effortlessly. |
t*******e
发帖数: 684 | 19 It is a separation of concerns. Rather having the UI developers to reinvent
the wheel, component vendors package their products which are ready to be
used off-the-shelf by application developers.
p
mo
jboss)
serve
suppose
【在 e*****t 的大作中提到】
: I agree with this.
: By using js component based frameworks, front end UI developers can easily p
: rototype UI desgins without much backend interaction.
: Our UI developers do their prototyping or some bug fixing on some kind of mo
: ck server (tomcat based). They hate to bring up the full application (jboss)
: , which may take up to 15 mins to start, not to mention the data setup.
: On the other hand, JSP/JSFs are used to server the http requests. They serve
: r the pages, and it works well for big page level components. But I suppose
: that's not the original purpose of JSF.
:
|
g*****g
发帖数: 34805 | 20 It's not re-inventing the wheels, the components can be in pure html/js.
And they are not tied to particular server technology or language. I would
argue that the library is richer and better that way.
reinvent
【在 t*******e 的大作中提到】
: It is a separation of concerns. Rather having the UI developers to reinvent
: the wheel, component vendors package their products which are ready to be
: used off-the-shelf by application developers.
:
: p
: mo
: jboss)
: serve
: suppose
|
|
|
t*******e
发帖数: 684 | 21 Put it this way, for most companies out there, component approach is more
cost-effective. Big players need to invent brand new widgets and eliminate
ties to any particular software vendor, html/js is the way to go.
【在 g*****g 的大作中提到】
: It's not re-inventing the wheels, the components can be in pure html/js.
: And they are not tied to particular server technology or language. I would
: argue that the library is richer and better that way.
:
: reinvent
|
e*****t
发帖数: 1005 | 22 I think everyone is on the same page.
For us, we need to build our own js component libraries on top of 3rd party
js frameworks (namely jquery and etc).
3rd party js component only deal with very low level components, and we need
bigger more integrated components. They typically have the data exchange in
terfaces well defined. Advantages are:
1. Consistent look and feel across different modules
2. easier css customization
3. underlying techonology agnostic, it can be java, ruby, even php.
【在 g*****g 的大作中提到】
: It's not re-inventing the wheels, the components can be in pure html/js.
: And they are not tied to particular server technology or language. I would
: argue that the library is richer and better that way.
:
: reinvent
|
t*******e
发帖数: 684 | 23
真不容易。
【在 e*****t 的大作中提到】
: I think everyone is on the same page.
: For us, we need to build our own js component libraries on top of 3rd party
: js frameworks (namely jquery and etc).
: 3rd party js component only deal with very low level components, and we need
: bigger more integrated components. They typically have the data exchange in
: terfaces well defined. Advantages are:
: 1. Consistent look and feel across different modules
: 2. easier css customization
: 3. underlying techonology agnostic, it can be java, ruby, even php.
|
b******y
发帖数: 9224 | 24
同感，呵呵
【在 t*******e 的大作中提到】
:
: 真不容易。
|
z****e
发帖数: 54598 | 25 我这边的一个法国军工巨头在用jsf
我看页面后缀是.jsf
【在 t*******e 的大作中提到】
: 现在没人用plain JSF，都有用RIA libs, 像primefaces之类，有javascript
: abstraction，开发效率非常高。没有component model+js abstraction，让你几个月
: 时间开发上百页的RIA app，无法想象。healthcare为例，会有很长的workflow，复杂
: 的forms。
: nodejs适合有js背景的人用，局限也不少。
: 关于web framework的争论一直都在，很多年前关于wicket就在本版讨论的很火爆。不
: 知道现在wicket还安好。孰优孰劣本无定论。都是根据具体要求和developers的背景决
: 定使用的技术。
|
z****e
发帖数: 54598 | 26 jsf sap的jee server不支持
貌似sap对jee6指责颇多
我看了下jee7，上个月发布了
发现jsp又被加上去了
不过我们坚持用freemarker
thymeleaf貌似对freemarker什么指责颇多
我找时间了解看看
【在 o**1 的大作中提到】
: jsf 还在坚持，也改变了很多，但是还是用的人不多。
: jsp就是所有 container都支持，不用什么额外的 jar.
: 最好的 template engine 是 thymeleaf, 几乎能想到的方便的地方它都有。
: 也非常适合美工和程序员合作。
|
z****e
发帖数: 54598 | 27 这里有个对比
貌似thymeleaf评价颇高啊
全部yes的只有两个，另外一个不开源
剩下的就只有thymeleaf了
http://en.wikipedia.org/wiki/Template_engine_(web) |
t*******e
发帖数: 684 | 28 和Spring Web Flow一起用后缀就没有了。最好也是和Spring Web Flow一起用，有很多
JPA相关的好处。
【在 z****e 的大作中提到】
: 我这边的一个法国军工巨头在用jsf
: 我看页面后缀是.jsf
|
r*****s
发帖数: 985 | 29 If you are building your own js components,
you should use ExtJs.
It's already componentized at js layer.
JQuery is for small projects.
party
need
in
【在 e*****t 的大作中提到】
: I think everyone is on the same page.
: For us, we need to build our own js component libraries on top of 3rd party
: js frameworks (namely jquery and etc).
: 3rd party js component only deal with very low level components, and we need
: bigger more integrated components. They typically have the data exchange in
: terfaces well defined. Advantages are:
: 1. Consistent look and feel across different modules
: 2. easier css customization
: 3. underlying techonology agnostic, it can be java, ruby, even php.
|
e*****t
发帖数: 1005 | 30 they might be using it. it's managed by the common UI team, and I'm backend.
:-)
【在 r*****s 的大作中提到】
: If you are building your own js components,
: you should use ExtJs.
: It's already componentized at js layer.
: JQuery is for small projects.
:
: party
: need
: in
|
|
|
c*********e
发帖数: 16335 | 31 恩，在extjs里，可以做很多功能，比如定制右击鼠标菜单，在一个树menu里右击来增
加节点。
【在 r*****s 的大作中提到】
: If you are building your own js components,
: you should use ExtJs.
: It's already componentized at js layer.
: JQuery is for small projects.
:
: party
: need
: in
|
s******e
发帖数: 493 | 32 I do not think that you can compare JSF to servlet. JSF was introduced by
sun trying to compete with other application tier technologies such as
struts, spring mvc... Like all those web frameworks, jsf is based on Servlet
. Actually without jsp/servlet spec, none of those java based web frameworks
will ever work at all. JSF, not like other web frameworks, is designed
using page controller pattern, which is subtly different from front
controller patterns used by most other popular web frameworks.
For the future of servlet and servlet based frameworks, I do not think it
will die soon considering huge investments and open source efforts put in
the area. Actually till today, I do not see any new technology will be able
to replace servlet soon. web/restful services were long said to be the best
candidate to retire servlet, but it fall short of the task. Now server side
js is viewed to be the next one... |
