67,513
社区成员
发帖
与我相关
我的任务
分享Tapestry!!希望更多人来学习讨论......
刚开始接触Tapestry，其OO&Components似乎真的很吸引......
希望更多的人来学习，讨论，分享经验。
我，菜鸟一个。
引两篇文章过来，有兴趣的看看。
http://dev.csdn.net/develop/article/27/27850.shtm
http://www.yesky.com/SoftChannel/72342371961929728/20031124/1747436.shtml
希望更多的人来学习，讨论，分享经验。
我，菜鸟一个。
引两篇文章过来，有兴趣的看看。
http://dev.csdn.net/develop/article/27/27850.shtm
http://www.yesky.com/SoftChannel/72342371961929728/20031124/1747436.shtml
...全文
请发表友善的回复…
发表回复
noncelebrity 2004-08-15
- 打赏
- 举报
我觉得关键是组件的设计与实现.
还要解决的是测试的问题.
现在我是每改动一点点东西都得redeploy.....
只有不断学习了..
不过现在的人气不是很高.
官方现在有个论坛,人气不是一般的低啊.
还要解决的是测试的问题.
现在我是每改动一点点东西都得redeploy.....
只有不断学习了..
不过现在的人气不是很高.
官方现在有个论坛,人气不是一般的低啊.
dengyin2000 2004-08-13
- 打赏
- 举报
多少官方网站学习！
noncelebrity 2004-08-11
- 打赏
- 举报
楼上的可否介绍一下经验.
能看看你们公司的成品么?
现在发现,开发时候的测试还不是很好做.我以为.
还不能利用JUnit等,在TDD叫的那么火的情况下,这是需要考虑的.
那位大虾有经验的,欢迎也很希望能共享一下.
谢谢!
能看看你们公司的成品么?
现在发现,开发时候的测试还不是很好做.我以为.
还不能利用JUnit等,在TDD叫的那么火的情况下,这是需要考虑的.
那位大虾有经验的,欢迎也很希望能共享一下.
谢谢!
dengyin2000 2004-08-11
- 打赏
- 举报
我们公司就是用TAPESTRY 开发的 刚进公司的时候 花了点时间学习
beming 2004-08-10
- 打赏
- 举报
已经了解过，打算学习中
noncelebrity 2004-08-10
- 打赏
- 举报
不了解JSF.以下内容来自网上:(说的有点那个,JSF作为标准和.Net WebForms叫板的东西应该也是很有....)
--------------------------
JSF is a set of APIs, wrapped by Taglibs, for use (mostly) in JSP pages.
JSF claims to be a component framework, but its JSP and Taglib roots are
simply dragging it back and preventing it from really achieving its goals.
Here is just _one_ example -- defining components.
In order to define a new component in Tapestry you need to do:
1. Declare the component specification (parameters, etc) in a .JWC file
2. Create the component template and save it into a .HTML file
3. [optional] Write the component logic into a Java Bean
4. [optional] Declare the component in the application or in a library
Also, the UI of the component is defined in a template that is easy to
understand and modify by a web designer or another developer; components and
pages are pretty much the same -- there is little fundamental difference
between the two -- the concepts that a developer has to deal are just a
single set.
In contrast, here is the procedure you must follow to define a new JSF
component according to the JSF tutorial:
----------------------8<-------------------------
1. Write a tag handler class that extends javax.faces.webapp.FacesTag. In
this class, you need:
. A getRendererType method, which returns the type of your custom
renderer, if you are using one (explained in step 4).
. A getComponentType method, which returns the type of the custom
component.
. An overrideProperties method, in which you set all of the new
attributes of your component.
2. Create a tag library descriptor (TLD) that defines the custom tag.
3. Create a custom component class
4. Include the rendering code in the component class or delegate it to a
renderer (explained in step 6).
5. If your component generates events, queue the event on the FacesContext.
6. Delegate rendering to a renderer if your component does not handle the
rendering.
a. Create a custom renderer class by extending
javax.faces.render.Renderer.
b. Register the renderer to a render kit.
c. Identify the renderer type in the component tag handler.
7. Register the component
8. Create an event handler if your component generates events.
9. Declare your new TLD in your JSP page and use the tag in the page.
---------------------->8-------------------------
In addition, the UI of new components is defined very differently and is
much more dificult to understand than the UI of JSP pages. Typically this is
done in the Java code itself -- there has been no effort to make the
code/HTML separation as in Tapestry.
Given all this, I can only conclude that JSF essentially _discourages_
developers from building his own components, and instead use standard ones
provided by a "guru" who has time and can expend the effort to do and test
all of the above.
Writing components-based apps for JSF is like writing OO code in C -- it is
certainly possible, but it is much more difficult than doing it by using a
language designed for that purpose.
Just to conclude -- there is a big _conceptual_ difference between the two
frameworks in general:
Tapestry was built from the ground up with a specific philosophy in mind --
"objects, methods, properties" rather than strings and URLs, and if I may
add, "simplicity, modularity, scalability" rather than a complex political
marriage of different technologies. During the design of Tapestry Howard has
not been afraid to throw away what does not work and utilize only ideas that
make life for developers easier.
On the other hand JSF constitutes a blank refusal to let go of legacy
technologies that are limited in scope, have proved problematic in
large-sclae development, and instead come up with something new and
effective. It simply piles up complexity on top of the existing approaches
and refuses to acknowledge the errors of the past. At the end, tools may
compensate a little for the complexity of JSF development, but they simply
cannot resolve the fundamental issues.
Frankly, I am quite disappointed with JSF -- it will probably cause more
problems than it will resolve. It could have been a far better framework if
it had not voluntarily taken upon the above design limitations. Pity that
Sun will try to ram it down everybody's throat, but it is questionable how
much people can take if it is their productivity that suffers.
--------------------------
JSF is a set of APIs, wrapped by Taglibs, for use (mostly) in JSP pages.
JSF claims to be a component framework, but its JSP and Taglib roots are
simply dragging it back and preventing it from really achieving its goals.
Here is just _one_ example -- defining components.
In order to define a new component in Tapestry you need to do:
1. Declare the component specification (parameters, etc) in a .JWC file
2. Create the component template and save it into a .HTML file
3. [optional] Write the component logic into a Java Bean
4. [optional] Declare the component in the application or in a library
Also, the UI of the component is defined in a template that is easy to
understand and modify by a web designer or another developer; components and
pages are pretty much the same -- there is little fundamental difference
between the two -- the concepts that a developer has to deal are just a
single set.
In contrast, here is the procedure you must follow to define a new JSF
component according to the JSF tutorial:
----------------------8<-------------------------
1. Write a tag handler class that extends javax.faces.webapp.FacesTag. In
this class, you need:
. A getRendererType method, which returns the type of your custom
renderer, if you are using one (explained in step 4).
. A getComponentType method, which returns the type of the custom
component.
. An overrideProperties method, in which you set all of the new
attributes of your component.
2. Create a tag library descriptor (TLD) that defines the custom tag.
3. Create a custom component class
4. Include the rendering code in the component class or delegate it to a
renderer (explained in step 6).
5. If your component generates events, queue the event on the FacesContext.
6. Delegate rendering to a renderer if your component does not handle the
rendering.
a. Create a custom renderer class by extending
javax.faces.render.Renderer.
b. Register the renderer to a render kit.
c. Identify the renderer type in the component tag handler.
7. Register the component
8. Create an event handler if your component generates events.
9. Declare your new TLD in your JSP page and use the tag in the page.
---------------------->8-------------------------
In addition, the UI of new components is defined very differently and is
much more dificult to understand than the UI of JSP pages. Typically this is
done in the Java code itself -- there has been no effort to make the
code/HTML separation as in Tapestry.
Given all this, I can only conclude that JSF essentially _discourages_
developers from building his own components, and instead use standard ones
provided by a "guru" who has time and can expend the effort to do and test
all of the above.
Writing components-based apps for JSF is like writing OO code in C -- it is
certainly possible, but it is much more difficult than doing it by using a
language designed for that purpose.
Just to conclude -- there is a big _conceptual_ difference between the two
frameworks in general:
Tapestry was built from the ground up with a specific philosophy in mind --
"objects, methods, properties" rather than strings and URLs, and if I may
add, "simplicity, modularity, scalability" rather than a complex political
marriage of different technologies. During the design of Tapestry Howard has
not been afraid to throw away what does not work and utilize only ideas that
make life for developers easier.
On the other hand JSF constitutes a blank refusal to let go of legacy
technologies that are limited in scope, have proved problematic in
large-sclae development, and instead come up with something new and
effective. It simply piles up complexity on top of the existing approaches
and refuses to acknowledge the errors of the past. At the end, tools may
compensate a little for the complexity of JSF development, but they simply
cannot resolve the fundamental issues.
Frankly, I am quite disappointed with JSF -- it will probably cause more
problems than it will resolve. It could have been a far better framework if
it had not voluntarily taken upon the above design limitations. Pity that
Sun will try to ram it down everybody's throat, but it is questionable how
much people can take if it is their productivity that suffers.
zhl44 2004-08-09
- 打赏
- 举报
非常不错
http://dev.csdn.net/article/20/20103.shtm
http://dev.csdn.net/article/20/20103.shtm
zhufanamo 2004-08-07
- 打赏
- 举报
感觉与jsf 差不多~~~~
用过sun的creator后的感觉也是这样
用过sun的creator后的感觉也是这样
noncelebrity 2004-08-06
- 打赏
- 举报
自己再顶一个.....
疯狂学习中.....
什么时候能上马做项目呢??
学习...学习...再学习
疯狂学习中.....
什么时候能上马做项目呢??
学习...学习...再学习
