|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 56
Messages: 56
Messages: 56
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
JCP Releases JavaServer Faces 1.0
The long-anticipated final version of the JavaServer Faces (JSF) specification 1.0 has been released. As Sun said on its ballot notes "This has been a long road. I'm glad to see this important JSR coming in for final approval!"
The approval ballot is available, and shows that everyone voted "Yes" (apart from Apple who didn't vote).
Sun's official description of JSF is:
"JavaServer[TM] Faces technology simplifies building user interfaces for JavaServer applications. With the well-defined programming model that JavaServer Faces provides, developers of varying skill levels can quickly and easily build web applications by: assembling reusable UI components in a page, connecting these components to an application data source, and wiring client-generated events to server-side event handlers. With the power of JavaServer Faces technology, these web applications handle all of the complexity of managing the user interface on the server, allowing the application developer to focus on application code."
Download JSF 1.0 final draft and RI
I've also written a short editorial about why JSF is significant, and what we can expect to see in the future: JavaServer Faces 1.0 has been released, but why does it matter?
|
|
|
Message #112932
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Granularity of Components
It should be interesting seeing what the granularity of the JSF components ends up being. Menu's, Calendars and Tree controls will be fun to start but what I'd really like to see are Forum's, Webmail, Photo Albums, Blogs etc. so that Java can finally start competing zope or php as a web frontend framework.
|
|
|
Message #112968
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
At the end, yes folks, we reach the top of the complexity => HTML, XML,
(xxx)ML programming language, congrats to JSF!
Check out this JSF tutorials:
http://www.exadel.com/tutorial/jsf/jsftutorial-kickstart.html
For a "Hello World" JSF application, you need:
- *one* Java file (Great, only one!)
- *tons* of (xxx)ML files. Cool, I really love XML files. I'm the new
generation of the most-up-to-date XML programmers: Everything: process,
functions, datas, objects are XML, yes!
Anyway, who can read such a JSP file below (this should be a HTML file?)
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:loadBundle basename="bundle.Messages" var="Message"/>
<HTML>
<HEAD> <title>Input Name Page</title> </HEAD>
<body>
<f:view>
<h1><h:outputText value="#{Message.inputname_header}"/></h1>
<h:messages style="color: blue"/>
<h:form id="helloForm">
<h:outputText value="#{Message.prompt}"/>
<h:inputText id="userName" value="#{PersonBean.userName}" required="true">
<f:validateLength minimum="2" maximum="10"/>
</h:inputText>
<h:commandButton id="submit" action="sayhello" value="Say Hello" />
</h:form>
</f:view>
</HTML>
Nobody can read such a file (and creating them by hand, o gosh...). My
conclusion on JSF:
- JSF is (xxx)ML friendly. Cool!
- JSF is tool vendors friendly. Without a tool, you can forget it. So
why not directly designed JSF as a "meta model" which fits into MOF
(Meta Object Facility) repository? Here we don't need to read those
(xxx)ML files, because they are used from "maschine" to "maschine". In
this case we can use MOF Management tool, which should be available
somewhere to do our:
- Modelling with UML
- Modelling for the datamodel
- and modelling for JSF (OK, this is going too far ;-))
Yep, one tool for all!
Until we can have the JSF within the MOF, I stay KISS: use Enhydra XMLC
with EAF or Barracuda. Check out Barracuda for sophisticated MVC
framework (long running events, localization, components, etc.):
http://barracudamvc.org/Barracuda/index.html
Cheers,
Lofi.
http://www.openuss.org
BTW 1, this would be a good new project for AndroMDA team. Creating
those (xxx)ML, JSPs automatically from the UML diagram just like
BPM4Struts ;-)
BTW 2, a good reason for Compuware with its OptimaJ to make a new study,
especially using JSF as the presentation layer. Maybe we can get 100%
productivity?
|
|
|
Message #112970
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
After all these years this is what they come up with!? A framework that makes Struts look like a miracle of simplicity.
It's technologies like this that makes you wonder why not everyone leaves Java for .NET. (think ASP.NET, what JSF should have been like if they had not insisted on building it on top of JSP)
I love Java. It's simple, elegant and still powerful. But why must so many J2EE technologies be the total anti-thesis of the underlying platform? Complicated, bloated, over-engineered.
|
|
|
Message #112996
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
I guess some people round here are missing JSF's point, some clarifications:
- yes, you will use a tool to draw your web interface in JSF, it was meant to be this way, but if you really want to, you can code it by hand. After some time I was able to deal with the specific JSP coding for the pages, if you have ever done some JSP then it will be a breeze.
- yes, configure it using xml. How else would you configure it? in Java source code? It is configuration, not code, that is done in the XML files.
- no, it is not a direct competitor to Structs, they can happly live toguether in the same project, only few areas are overlapping on both technologies, and there is already a library for integrating both.
- yes, it is simple! Once you get used to its workings, of course, just like most new technology out there. Don't expect it to save world from hunger from night do day though. It will begin to really shine when tools based on the spec starts to appear.
- no, it is not build on top of JSP. JSP is just one of the possible "interfaces" for JSF, the one used by the RI. You can use XLST if you prefer that. Or you can create you own rendering engine, based on a different technology, or use the ones that will surely be created by open-source or companies.
Regards,
Henrique Steckelberg
|
|
|
Message #112999
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
Lofi,
I beg to differ: JSF is not by any means another (xxx)ML language as you are stating. The XML files cited on exadel's tutorial are just configuration files you will see on any servelet server out there. The only exception is the JSF configuration file itself, and even that file doesn't have any "code" in it, just configuration parameters. It is not a new language. So of these "tons" of XML files you have to edit, there's just one new one, so for a simple application, tons equals 2 (web.xml and jsf-config.xml). ;) And for big applications, these XML config files would still be few.
Regards,
Henrique Steckelberg
|
|
|
Message #113004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Hurray, Model 2 again
Some things just drive me mad. For example, why a *new* framework is still coming up with the model 2 "architecture" (The JSF Servlet), an architecture that is extremely useful if you want to give away concise urls, bookmarking and above all the J2EE / servlet security model. And all this comes with almost no usable components at all. Since I will probably not be able to mix and match implementations, I will be stuck with a single vendor! Wow, that is some real change! Well done, and back to school!
|
|
|
Message #113006
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
> Anyway, who can read such a JSP file below (this should be a HTML file?)
>
> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
> <f:loadBundle basename="bundle.Messages" var="Message"/>
>
> <HTML>
> <HEAD> <title>Input Name Page</title> </HEAD>
> <body>
> <f:view>
> <h1><h:outputText value="#{Message.inputname_header}"/></h1>
> <h:messages style="color: blue"/>
> <h:form id="helloForm">
> <h:outputText value="#{Message.prompt}"/>
> <h:inputText id="userName" value="#{PersonBean.userName}" required="true">
> <f:validateLength minimum="2" maximum="10"/>
> </h:inputText>
> <h:commandButton id="submit" action="sayhello" value="Say Hello" />
> </h:form>
> </f:view>
> </HTML>
>
> Nobody can read such a file (and creating them by hand, o gosh...). My
Really? Looks like a pretty normal jsp page using taglibraries to me.
Br - J
|
|
|
Message #113013
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
I think it looks like a normal JSP page with taglibs. Actually ASP.NET will be similar (maybe except this part: action="sayhello" – direct coding for actions). The complexity is in the deployment: web.xml and jsf-config
But in general I agreed. In the current state JSF can not compete with ASP.NET
Just adds the complexity without the real advantages
Dmitry Namiot
Coldbeans
|
|
|
Message #113026
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Exactly the same!
<quote>
Really? Looks like a pretty normal jsp page using taglibraries to me.
</quote>
Yep and this is exactly what I want to say. Just the same as JSP with TagLibs ==> horrible ;-) I had a hope that JSF would be a better way than JSP with TagLibs...
Cheers,
Lofi.
|
|
|
Message #113031
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
Henrique,
yes, you are correct. Maybe I just hope too much from the JSF team ;-) I thought JSF would be something new, where we can say, allright folks, here we have a simple good way to write our web presentation layer! Something innovative. But JSF is just a mix from the technologies we already had (JSP, Servlet, XML configs, Taglibs).
What disturb me is that the "tool orientation" of JSF. I feel that if you need some sophisticated tools for your work, it seems that the design was not good enough. Except that you plan this in the front. But as I said, this would be a good thing for MDA ;-)
Cheers,
Lofi.
|
|
|
Message #113034
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is JSF replacement for Struts.
Looking at the exadel's tutorial and I agree with other folks that it is JSP with taglibraries. So whats the real advantage of using JSF ? and for those who are already using struts (<html/>) tag library
Also, why would one use JSF and struts in same project?
|
|
|
Message #113035
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
>I guess some people round here are missing JSF's point, some clarifications:
As per me the main point I am missing is why do we need JSF?
Why the rapid UI development could not be done without this? What is wrong in the existing tools? Yes, there are much less components comparing with ASP.NET, but JSF also does not help too much here. And if we will talk about MDA the underlying technology we are using in our code generation is not so important at all
Maybe it is about plug-ins interoperability? But I this case it is not about end-users (developers)
>It will begin to really shine when tools based on the spec starts to appear.
So tools will be shine, not a JSF. It is not about sarcasm, I am really interested
Dmitry Namiot
Coldbeans
|
|
|
Message #113036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
> Henrique,
>
> yes, you are correct. Maybe I just hope too much from the JSF team ;-) I thought JSF would be something new, where we can say, allright folks, here we have a simple good way to write our web presentation layer! Something innovative. But JSF is just a mix from the technologies we already had (JSP, Servlet, XML configs, Taglibs).
Yes, but as I said before, JSF is not tied to JSP, you can create your web pages in JSF using XLST for example, and other solutions will appear too. If you use Smile for example, an Open Source implementation of JSF, you can code your pages in Java, just like when you code Swing UI.
OTOH, to expect that a totally new technology would be created out of nothing would be crazy, I guess. Imagine just throwing away all the knowledge and experience regarding Servlet servers, APIs and everything else. JSF is very flexible in this regard, you can adapt it to work on different technologies, not just JSP.
>
> What disturb me is that the "tool orientation" of JSF. I feel that if you need some sophisticated tools for your work, it seems that the design was not good enough. Except that you plan this in the front. But as I said, this would be a good thing for MDA ;-)
Well, I expect that the tools you will need will be very similar to today's Swing or VB-like drag-and-drop editors, which need not be too sophisticated IHMO, nothing different from ASP.Net, for example, and very common in UI developement. And AFAIK, JSF was planned from the beggining to be suported by tools in this manner, being it based on JavaBean UI components.
I just can't see how you would use an MDA tool to create UI code and config, though. Is it about automatic forms and navigation code creation, or am I missing something here?
Regards,
Henrique Steckelberg
>
> Cheers,
> Lofi.
|
|
|
Message #113038
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Exactly the same!
> <quote>
> Really? Looks like a pretty normal jsp page using taglibraries to me.
> </quote>
>
> Yep and this is exactly what I want to say. Just the same as JSP with TagLibs ==> horrible ;-) I had a hope that JSF would be a better way than JSP with TagLibs...
>
So had I, and I am still hoping. The main benefit of JSF is that it has the potential to become so adopted that we get great tool support for it. Lets face it, graphical user interfaces should be designed (and implemented) using visual tools, not text editors. So, what I hope for in JSF is not a easier-to-read source file - it is not to have to read the source file at all.
|
|
|
Message #113043
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
> >I guess some people round here are missing JSF's point, some clarifications:
>
> As per me the main point I am missing is why do we need JSF?
JSF is about the specification, not the RI. The RI is just a proof that the specification can work, it is not a comprehensive, production or market oriented product. But the specification was needed because of the miriad of web frameworks that appears almost daily, and to fight againts ASP.Net competition. JSF will help to lower the fragmentation of the market in this area, where you have 1000's of different solutions to the same problem. I don't expect all the other web frameworks to disappear, but having an "official" specification can surely help us go on a common direction and avoid so much dispersing.
>
> Why the rapid UI development could not be done without this? What is wrong in the existing tools? Yes, there are much less components comparing with ASP.NET, but JSF also does not help too much here. And if we will talk about MDA the underlying technology we are using in our code generation is not so important at all
>
The JSF RI has just a few components, but as I said before, it is not a product, it is just a proof of concept. Tools vendors and Open Source project will create new components that you will be able to use on any JSF compliant implementation, just like you can do with VB and Swing, for example. I can't see where MDA fits in this picture though, but maybe you are using MDA to autogenerate forms and navigation code.
> Maybe it is about plug-ins interoperability? But I this case it is not about end-users (developers)
>
> >It will begin to really shine when tools based on the spec starts to appear.
> So tools will be shine, not a JSF. It is not about sarcasm, I am really interested
The tools are just that, they will help you create your UI much more easily than hand-coding JSP, for example. Having JSF specification behind these tools will enable us to use components downloaded from an Open Source project, or even create our own library of components that fit our specific needs. This will enable the growth of a UI components market too. Using JSF will help enforce the MVC pattern in projects... There are lots of benefits os having an specification like JSF in Java.
Henrique Steckelberg
|
|
|
Message #113045
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is JSF replacement for Struts.
> Looking at the exadel's tutorial and I agree with other folks that it is JSP with taglibraries. So whats the real advantage of using JSF ? and for those who are already using struts (<html/>) tag library
JSF focus is on the UI itself, not the backing Java code behind the web pages. And Structs focus is on the backing code, OTOH, not the UI, so actually both technologies are complimentary. Both have some common functionalities, but you have to leverage on each one's strength.
>
> Also, why would one use JSF and struts in same project?
This way, you will be able to leverage upon the tools and UI components for JSF that are expected to to appear on the market soon. These tools are expected to booster your performance for web UI development. If you already have a project using structs, it is easy to convert it to a JSF-structs one, by the way, using the JSF-Struct integration library.
|
|
|
Message #113047
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA and JSF
<quote>
I just can't see how you would use an MDA tool to create UI code and config, though. Is it about automatic forms and navigation code creation, or am I missing something here?
</quote>
You don't implement the presentation layer UI directly in such a MDA tool. But at least you can generate all the "skeletons":
- Design the whole workflow of your application in combination of use case, activity and class diagrams. Mark them with <<stereotype>>.
>
- Generate the skeletons of your JSPs or HTMLs or WMLs, Servlets, XML configs, your base framework from the diagrams, etc. Everything what you need to begin.
- Implement the rest (like refine the JSPs or HTMLs, etc.).
- Back to the top in iterative way.
Check out the great work from Wouter Zoons at AndroMDA with his BPM4Struts (Business Process Modelling for Struts with AndroMDA):
http://team.andromda.org/tiki/tiki-index.php?page=Bpm4StrutsHowTo&PHPSESSID=e4b9e6e46dd3b54e321960d9f5a08a4e
And Dmitry is right by saying "And if we will talk about MDA the underlying technology we are using in our code generation is not so important at all". Yep, build a new cartridge and port your code ;-)
Regards,
Lofi.
|
|
|
Message #113055
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA and JSF
Lofi,
Based on your explanation, I can't see why JSF couldn't fit on a MDA tool, then. My guess is that it could even create some skeleton code for data entry forms, not just navigation code, but that is just me shooting in the dark.
Here we can see another advantage of JSF specification: you won't have to create 100s of plugins, one for structs, other for tapestry, other for Echo, W4E, etc., in the future. As long as you use an JSF compliant web framework, only one JSF plugin for your MDA tool will do.
Regards,
Henrique Steckelberg
|
|
|
Message #113057
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
overlap with struts?
I've read a few times that JSF and Struts have only minory overlapping points. As does Henrique mention here.
I fail to see that: Struts provides actions, a way to string them together with pages into a flow, internationalization and webcomponents (Tiles).
JSF provides the same. (But better designed imo.)
So what's complementary in Struts that's not offered by JSF?
groetjes,
Joost
|
|
|
Message #113059
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
> Yes, but as I said before, JSF is not tied to JSP, you can create your web pages in JSF using XLST for example, and other solutions will appear too. If you use Smile for example, an Open Source implementation of JSF, you can code your pages in Java, just like when you code Swing UI.
>
What license has the RI been released under? Can an opensource implementation borrow from the RI? Is it realistic for an opensource JSF implementation to implement the spec? Will it be able to get access to any test and compatibility kits?
> OTOH, to expect that a totally new technology would be created out of nothing would be crazy, I guess. Imagine just throwing away all the knowledge and experience regarding Servlet servers, APIs and everything else. JSF is very flexible in this regard, you can adapt it to work on different technologies, not just JSP.
>
Not to throw out the KNOWLEDGE we've gained, just the technologies that knowledge have pointed out as overly complex and bloated, such as JSP. Of course, Sun isn't going to build a RI using a non "standard", such as Velocity, Freemarker, etc... A shame, really.
>
> Well, I expect that the tools you will need will be very similar to today's Swing or VB-like drag-and-drop editors, which need not be too sophisticated IHMO, nothing different from ASP.Net, for example, and very common in UI developement. And AFAIK, JSF was planned from the beggining to be suported by tools in this manner, being it based on JavaBean UI components.
>
I think it's telling that most people I've heard who do real application development (not just toy prototypes or quick one-screen apps) hand code their Swing code, rather than the GUI builders...
Jason
|
|
|
Message #113060
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
>
> JSF is about the specification, not the RI. The RI is just a proof that the specification can work, it is not a comprehensive, production or market oriented product. But the specification was needed because of the miriad of web frameworks that appears almost daily, and to fight againts ASP.Net competition. JSF will help to lower the fragmentation of the market in this area, where you have 1000's of different solutions to the same problem. I don't expect all the other web frameworks to disappear, but having an "official" specification can surely help us go on a common direction and avoid so much dispersing.
>
So a bloated and over-engineered "Standard" is going to help this how? I don't understand this need Sun has of looking at a space with a lot of mature projects and decide to start from scratch and build something not as good as the currently available options. From what I've seen I'd choose WebWork, Tapesty, or even Struts over JSF.
|
|
|
Message #113061
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA and JSF
<quote>
Based on your explanation, I can't see why JSF couldn't fit on a MDA tool, then. My guess is that it could even create some skeleton code for data entry forms, not just navigation code, but that is just me shooting in the dark.
</quote>
Sorry if I was not clear enough ;-) Surely JSF fits 100% to MDA tools. Therefore my comment about 100% more productivity for TSS case study with Compuware if they would use JSF ;-) And yes, using tag values in UML, you can generate validation code, navigation code, config files, etc.
The big question for me is that what kind of UI components (presentation layer) you think you will get from JSF? If we take HTML as example, I cannot see that you need "more" components. At the end HTML limits us to do this (I'm not talking about JavaScript and Java Applet or other Dynamic HTML from MSIE, just plain HTML). Remember that this is not a Swing UI presentation layer, where you can have rich UI...
Using JSF as component is different than creating a JSF component, right?
Regards,
Lofi.
|
|
|
Message #113063
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
> > Yes, but as I said before, JSF is not tied to JSP, you can create your web pages in JSF using XLST for example, and other solutions will appear too. If you use Smile for example, an Open Source implementation of JSF, you can code your pages in Java, just like when you code Swing UI.
> >
>
> What license has the RI been released under? Can an opensource implementation borrow from the RI? Is it realistic for an opensource JSF implementation to implement the spec? Will it be able to get access to any test and compatibility kits?
>
I don't know about licensing or compatilibity kit (if there is one) details, but about being JSF realistic for OS implementation, given that there's already 2 OS implementations out there even before 1.0 release, I take it as a yes, it is feasible.
> > OTOH, to expect that a totally new technology would be created out of nothing would be crazy, I guess. Imagine just throwing away all the knowledge and experience regarding Servlet servers, APIs and everything else. JSF is very flexible in this regard, you can adapt it to work on different technologies, not just JSP.
> >
>
> Not to throw out the KNOWLEDGE we've gained, just the technologies that knowledge have pointed out as overly complex and bloated, such as JSP. Of course, Sun isn't going to build a RI using a non "standard", such as Velocity, Freemarker, etc... A shame, really.
>
I imagine that even tapestry (or any other component-oriented web framework) may be made JSF compliant, but thats a guess. And again: you don't have to use JSP in JSF, if you don't like it. One more thing: don't expect too much of a RI too, wait for OS or companies to implement more robust and comprehensive _implementations_ of JSF specification.
> >
> > Well, I expect that the tools you will need will be very similar to today's Swing or VB-like drag-and-drop editors, which need not be too sophisticated IHMO, nothing different from ASP.Net, for example, and very common in UI developement. And AFAIK, JSF was planned from the beggining to be suported by tools in this manner, being it based on JavaBean UI components.
> >
>
> I think it's telling that most people I've heard who do real application development (not just toy prototypes or quick one-screen apps) hand code their Swing code, rather than the GUI builders...
>
Well, you could do that in JSF too if you like (create your UI in code only), using Smile OS JSF, for example. My expectation is that I would be able to use a tool to create a basic UI, and then fine tune it in code, but that is my opinion only.
Some Links:
http://www.jsfcentral.com/ (Lots of Resources)
http://sourceforge.net/projects/myfaces/ (Open Source Implementation of JSF)
http://smile.sourceforge.net/index.html (Open Source Implementation of JSF)
http://jakarta.apache.org/struts/proposals/struts-faces.html (Struts-Faces discussion by Struts creator himself)
http://www.jamesholmes.com/JavaServerFaces/ (More Resources)
Regards,
Henrique Steckelberg
Henrique Steckelberg
|
|
|
Message #113066
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
> So a bloated and over-engineered "Standard" is going to help this how? I don't understand this need Sun has of looking at a space with a lot of mature projects and decide to start from scratch and build something not as good as the currently available options. From what I've seen I'd choose WebWork, Tapesty, or even Struts over JSF.
Some things here:
- JSF is a brand new specification, it doesn't have the same maturity as WebWork or Tapestry right now.
- JSF is not build from scratch, it is based on existing technologies: UI components, Java Beans, Servlets, XML, XLST, etc.
- I can't see what is so bloated or over-engineered about JSF, it is just as "bloated" and "over-engineered" as any other component-oriented web framework out there.
Wether JSF is as good as other existing web frameworks, only time will tell. If it ends up not being as good, we will continue using whatever web framework we already use today. OTOH, if it end up proving itself and a community evolves around it, then we will surely see the benefits I have already mentioned before about having this specification instead of none. Right now, it is all speculation. But in my opinion, it will find its place in web development.
Regards,
Henrique Steckelberg
|
|
|
Message #113067
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is JSF replacement for Struts.
>This way, you will be able to leverage upon the tools and UI components for
>JSF that are expected to to appear on the market soon.
So what if we will add UI components for Struts. Do we still need JSF?
Even from your words it looks like problem in components, not in the framework.
Dmitry Namiot
Coldbeans
|
|
|
Message #113069
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA and JSF
> <quote>
> Based on your explanation, I can't see why JSF couldn't fit on a MDA tool, then. My guess is that it could even create some skeleton code for data entry forms, not just navigation code, but that is just me shooting in the dark.
> </quote>
>
> Sorry if I was not clear enough ;-) Surely JSF fits 100% to MDA tools. Therefore my comment about 100% more productivity for TSS case study with Compuware if they would use JSF ;-) And yes, using tag values in UML, you can generate validation code, navigation code, config files, etc.
>
Fine! I will surely take a look at that, looks promising!
> The big question for me is that what kind of UI components (presentation layer) you think you will get from JSF? If we take HTML as example, I cannot see that you need "more" components. At the end HTML limits us to do this (I'm not talking about JavaScript and Java Applet or other Dynamic HTML from MSIE, just plain HTML). Remember that this is not a Swing UI presentation layer, where you can have rich UI...
>
It is not about "more" components, it is about having a different paradigm for web development, where you don't think about HTML tags, but about UI components just like in Swing or VB. You drop a component on a page during design, set some properties for it, add some coding behind it, and its done. At no time you will have to worry about URLs, getting variables from post requests, etc. That will be taken care for you automatically.
Another thing is that JSF allows for a pluggable renderer, so you could take the same JSF code and generate HTML, WAP, XML, or maybe even Swing UIs automatically, just by changing the rendering engine! Wouldn't it be nice? ;)
The nice thing about having UI components is reuse: if you create a calendar component for example, you could just drop it in multiple places, or even donate it for my project ;) so I wouldn't need to code it myself, I would just drop it where I needed it... :)
> Using JSF as component is different than creating a JSF component, right?
I think I don't get what you mean exaclty, but yes, these are completely different things. You could use JSF as a "interface component" of your system, but that wouldn't mean you would have to create JSF components, you could use the existing ones in the chosen implementation or the ones created by others.
There's already an Open Source Project for free JSF UI components:
http://www.ourvision.de/ourfaces/index.html
Regards,
Henrique Steckelberg
|
|
|
Message #113070
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is JSF replacement for Struts.
> >This way, you will be able to leverage upon the tools and UI components for
> >JSF that are expected to to appear on the market soon.
> So what if we will add UI components for Struts. Do we still need JSF?
> Even from your words it looks like problem in components, not in the framework.
If you already use struts in an production project, no, you dont need JSF. I was just pointing to some benefits of using it with struts, like expected tool support and complex components (like calendar, date entry fields, data tables, etc.) that could make your development faster. This would be most beneficial for new projects. Existing projects which are mature and don't expect much maintenance wouldn't benefit much (if anything) from adding JSF to structs.
Henrique Steckelberg
|
|
|
Message #113072
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Macromedia and JSF
I noticed that Macromedia voted "Yes" on the JSF 1.0 specification.
Is Macromedia planning to build any tools that support JSF 1.0?
Macromedia has been pushing hard with Flash/Flex/MXML/Remoting/WebServices
|
|
|
Message #113073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
>>Well, you could do that in JSF too if you like (create your UI in code only),
>>using Smile OS JSF, for example. My expectation is that I would be able to
>>use a tool to create a basic UI, and then fine tune it in code, but that is my opinion only.
Have you looked at Dynamator ( http://dynamator.sourceforge.net/ )? It may work well for many types of technologies. It looks similar to XMLC/Tapestry in terms of additional markup in the plain html documents, but does transformation in a separate development time step, so the result is as performant as underlying technology ( JSP, JSF, Velocity, PHP, ASP ). In the same time it allows leveraging existing HTML authoring tools like Dreamweaver.
|
|
|
Message #113082
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
Honestly guys, do you really believe that the "page-oriented, server-compiled" document is the future of the presentation layer? I doubt it...
Ovi
|
|
|
Message #113084
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
>>do you really believe that the "page-oriented, server-compiled" document
No!
I actually just waiting when X-Window server will be standard on clients. I am serious.
|
|
|
Message #113086
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA and JSF
<quote>
It is not about "more" components, it is about having a different paradigm for web development, where you don't think about HTML tags, but about UI components just like in Swing or VB. You drop a component on a page during design, set some properties for it, add some coding behind it, and its done. At no time you will have to worry about URLs, getting variables from post requests, etc. That will be taken care for you automatically.
</quote>
Allright, of course it would be nice to make drag&drop (but be sure to understand the underlying technology and technique first, because in case that your drag&drop environment does not work well, you need to dig into the sourcecode...) ;-) And surely it is nice to see how WSAD plays with JSF in this article:
http://www-106.ibm.com/developerworks/websphere/techjournal/0402_barcia/0402_barcia.html
Regards,
Lofi.
|
|
|
Message #113090
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF vs. BarracudaMVC
Check this mail to see the different between JSF and BarracudaMVC:
http://mail-archive.objectweb.org/barracuda/2003-09/msg00006.html
Copy&Paste comment from Christian Cryder (project chair Barracuda):
"My general "gut reactions" to JSR-127 are that its too tied to JSP for my
taste (I understand why Sun made this decision, but I think it will make it
very difficult for them to succeed in the long run). In theory JSF is not
bound to any specific rendering approach, but last time I checked the only
implementation being supported was via JSPs, so I think I'd agree with
Dudley's comments...to me, JSF looks like a souped up version of Struts. It
seems like its taking an awful long time to deliver anything. Its not going
to be open source when its finally released either (has this changed?). In
short, I think most of the "problems" I see with Struts still apply to JSF,
and I'm not at all sure why someone who is already using Struts would go to
the effort of migrating to JSF (but I'm sure there are folks here who could
comment on that). Consequently, I don't really see it as competing with
Barracuda because I think that even though they are using similar verbiage,
the architectures really are fundamentally different."
To: Henrique, it seems that JSF is too tight to JSP ;-)
Cheers,
Lofi.
|
|
|
Message #113103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
> Honestly guys, do you really believe that the "page-oriented, server-compiled" document is the future of the presentation layer? I doubt it...
>
server-compiled ? is someone still making the server compile their pages ? (*sarc*)
I remember the time where one would click on each link to discover compilation errors (and not to mention waiting 5+ secs for the page to appear) ... and even think it was normal to do so
for those people: it's 2004, come out of that hole in the ground and read this:
http://www.mail-archive.com/andromda-user@lists.sourceforge.net/msg00364.html
advantages:
1. detect compiler problems during development build processes
2. no need for the compiler on the server: more secure
3. pages load instantly: ALWAYS
to date I have never experienced problems with this approach
Wouter.
|
|
|
Message #113104
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Or just use myeclipseide
It syntax checks and compiles your jsp as you work. So you dont need to
run it on the server or write an ant script to compile it before deployment.
--B
|
|
|
Message #113110
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF vs. BarracudaMVC
> Check this mail to see the different between JSF and BarracudaMVC:
> http://mail-archive.objectweb.org/barracuda/2003-09/msg00006.html
>
> Copy&Paste comment from Christian Cryder (project chair Barracuda):
> "My general "gut reactions" to JSR-127 are that its too tied to JSP for my
> taste (I understand why Sun made this decision, but I think it will make it
> very difficult for them to succeed in the long run). In theory JSF is not
> bound to any specific rendering approach, but last time I checked the only
> implementation being supported was via JSPs, so I think I'd agree with
> Dudley's comments...to me, JSF looks like a souped up version of Struts. It
> seems like its taking an awful long time to deliver anything. Its not going
> to be open source when its finally released either (has this changed?). In
> short, I think most of the "problems" I see with Struts still apply to JSF,
> and I'm not at all sure why someone who is already using Struts would go to
> the effort of migrating to JSF (but I'm sure there are folks here who could
> comment on that). Consequently, I don't really see it as competing with
> Barracuda because I think that even though they are using similar verbiage,
> the architectures really are fundamentally different."
>
> To: Henrique, it seems that JSF is too tight to JSP ;-)
>
> Cheers,
> Lofi.
Lofi: this discussion seems dated to me:
- JSF is "open source", I have already given 2 links to open source implementations.
- the RI already comes with 2 rendering engines, one based on JSP and another based on XLST transformatinons, so this "JSP tie" is not true
- This is just Cristians' opinion, and being him project leader of a competing technology, what would you expect? ;)
JSF is not tied to JSP, the RI focused on JSP just because it would be an obvious choice for a proof of concept.
Henrique Steckelberg
|
|
|
Message #113113
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF vs. BarracudaMVC
Let me correct myself: the final 1.0 JSF RI doesn't come with a XLST renderer... it comes with a XUL renderer besides the JSP one! ;)
Regards,
Henrique Steckelberg
|
|
|
Message #113120
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
> http://www.mail-archive.com/andromda-user@lists.sourceforge.net/msg00364.html
Wouter,
While your approach is interesting and results in a performance boost, it addresses only the "compiled" part of the "page-oriented, server-compiled" issue. My question is, again: do we really have to present the user one page at a time and fetch it every time (pre-compiled or not) from the server? Or should we start building _real_ GUIs, rich ones?
Ovi
|
|
|
Message #113124
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Welcome to the most complex (xxx)ML programming language!
>
> I don't know about licensing or compatilibity kit (if there is one) details, but about being JSF realistic for OS implementation, given that there's already 2 OS implementations out there even before 1.0 release, I take it as a yes, it is feasible.
>
Right... and JBoss is an OpenSource J2EE implementation... oh, wait, it's not, legally.
|
|
|
Message #113130
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Actually I think JSF is wonderful
Going through the tutorial that was created for the EA version I found JSF far far better than Struts. Things were more logically organised than Struts and it removed a lot of the Struts junk that made Struts heavy. It was easier to understand page flow by looking at one XML file. It was also easier to create validations on components, setup the model values and define the messaging. One could look at a page and know exactly what it was doing and how. Using anonomous action classes or predefined flows made navigation a breeze. The is no need for Struts Actionforms, the translations between those and your Data Transfer Objects (DTO) are made redundant. Don't get me wrong, Struts was a great framework and save my ass on many a project but it has been superceeded by an even better framework.
Yes it is more complex than Struts, but not much more and the results will be worth it. Forget about GUI builders for JSF pages, someone once called them Rabid Application Builders - and with good reason. There is no re-use or componentization of code from page to page. Therefore your maintainability and performance suffer immensly, the advantages of Java are just thrown out.
JSF is the future, spend the time learning it and you will take off - just remember it's not even a thousandth of the complexity of EJB's, so there is nothing to worry about. Keep in mind that I am speaking as someone who will have to teach this framework to other Java developers.
-Karim
|
|
|
Message #113136
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Actually I think JSF is wonderful
>There is no re-use or componentization of code from page to page. Therefore
>your maintainability and performance suffer immensly, the advantages of Java
>are just thrown out.
Really? Or "no re-use" is an advantage?
>Keep in mind that I am speaking as someone who will have to teach this
>framework to other Java developers.
I see ...
Dmitry Namiot
http://www.servletsuite.com
|
|
|
Message #113141
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why I hate BarracudaMVC
I've learned and used BarracudaMVC. Here are what I think about it.
1. It generates too many objects on top of my application objects and this makes me question it's scaleability in big projects. For example, in BarracudaMVC you declare events in an events.xml file and implement handlers for them in your application gateway. Now, if you declare 200 events, in an ideal case you would want to implement one handler per event. In this case, you may end up with 400 extra objects on top of your application. What I find so annoying is why an object is generated for every event I declare in my events.xml. In fact, this is a framework that I think is over-engineerd.
2. Learning curve is extremely high. Documents are scattered around the site. Even some links that are provided to working examples fail to work. You get instead exceptions in your browser. Barracuda's examples falls into 2 categories, in my opinion. The first category consits of a set of useless and too simple examples. The second category consists of examples too complex to understand, as a starter, what is really going on. In fact, you can hardly learn how to create real applications from these examples. In between these 2 categories, for the most technologies, you find examples as well. But Barracuda has nothing there. So you waste a lot of time reading bad Javadocs and source code to find out how to achieve what you want done.
If you're unemployed and have abundance of time to play, then maybe the learning curve wouldn't be problem for you. But if you don't have much time, like most us employed developers, and want to do serious stuff then look somewhere else. You may want to look at Tapestry, well documented and a very well engineerd framework. I work with Struts and have taken a look at Tapestry. I'm now checking JSF too. With all these framworks there are enough well documented examples to get you up running quickly.
I've dumped BarracudaMVC in my trash can, thus no more hassles:)
Emmanuel
|
|
|
Message #113142
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCP Releases JavaServer Faces 1.0
> Wouter,
>
> While your approach is interesting and results in a performance boost, it addresses only the "compiled" part of the "page-oriented, server-compiled" issue. My question is, again: do we really have to present the user one page at a time and fetch it every time (pre-compiled or not) from the server? Or should we start building _real_ GUIs, rich ones?
>
hi Ovi,
oh I don't know ... both probably have their respective area in which they are best suited, I don't want to make any remarks on that; I was simply replying on the 'server-compiled' part of your message :-)
sorry for the confusion
b-bye
Wouter.
|
|
|
Message #113156
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF Components
> It should be interesting seeing what the granularity of the JSF components ends up being.>
I think developers won't wait so long for sophisticated JSF Java Web Components.
You can try that for a beginning : http://www.javawebcomponents.com
John Webber.
|
|
|
Message #113173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Actually I think JSF is wonderful
> JSF is the future, spend the time learning it and you will take off - just remember it's not even a thousandth of the complexity of EJB's, so there is nothing to worry about. Keep in mind that I am speaking as someone who will have to teach this framework to other Java developers.
>
> -Karim
Isn't the spec like 800 pages long?
|
|
|
Message #113187
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Actually I think JSF is wonderful
> > JSF is the future, spend the time learning it and you will take off - just remember it's not even a thousandth of the complexity of EJB's, so there is nothing to worry about. Keep in mind that I am speaking as someone who will have to teach this framework to other Java developers.
> >
> > -Karim
>
> Isn't the spec like 800 pages long?
Hey Jason, what is your problem?
|
|
|
Message #113296
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Macromedia and JSF
Macromedia will be at my seminar talking on their "JSF".
baseBeans.com to register ($99)
.V
PS:
Also presenting is Ted Husted (Struts), Matt Raible (Menu and Display tag),
Rod Johnson (EJB ... or not), Clinton Beign (iBatis), and me, on basicPortal.
|
|
|
Message #114036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Actually I think JSF is wonderful
The final release version of JSF looks much better than the EA4 release (they finally eliminated some of the warts and naming inconsistencies). Granted, it took me a day to rewrite all my code for v1.0...
I've used both Struts and JSF and I've got to say that JSF is cleaner and better designed than Struts. I would have expected no less since Craig McClanahan designed both and obviously had the advantage of studying the flaws in Struts before co-designing JSF.
Hand coding web apps in JSF will remain a tedious endeavor until tools come out to help automate the process. Let's hope they come out soon!
-Jeff
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
