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?
-
JCP Releases JavaServer Faces 1.0 (56 messages)
- Posted by: Kito Mann
- Posted on: March 03 2004 15:36 EST
Threaded Messages (56)
- Granularity of Components by random fletch on March 03 2004 17:28 EST
- JSF vs Nukes by Andrew Oliver on March 03 2004 19:05 EST
- JSF Forum by Sergey Smirnov on March 03 2004 11:18 EST
- JSF vs Nukes by Marina Prikaschikova on March 04 2004 08:21 EST
- There is mvnForum, opensource Jsp/Servlet forum by Minh Nguyen on March 03 2004 23:00 EST
- JSF Components by John Webber on March 05 2004 08:36 EST
- WebGalileo Faces 1.0 Java web components are available by John Webber on June 01 2004 07:14 EDT
- JSF vs Nukes by Andrew Oliver on March 03 2004 19:05 EST
- Welcome to the most complex (xxx)ML programming language! by Lofi Dewanto on March 04 2004 04:04 EST
- Welcome to the most complex (xxx)ML programming language! by Henrique Steckelberg on March 04 2004 09:58 EST
-
Welcome to the most complex (xxx)ML programming language! by Lofi Dewanto on March 04 2004 10:57 EST
-
Welcome to the most complex (xxx)ML programming language! by Henrique Steckelberg on March 04 2004 11:26 EST
-
MDA and JSF by Lofi Dewanto on March 04 2004 12:05 EST
-
MDA and JSF by Henrique Steckelberg on March 04 2004 12:43 EST
-
MDA and JSF by Lofi Dewanto on March 04 2004 01:15 EST
-
MDA and JSF by Henrique Steckelberg on March 04 2004 02:04 EST
- MDA and JSF by Lofi Dewanto on March 04 2004 03:46 EST
-
MDA and JSF by Henrique Steckelberg on March 04 2004 02:04 EST
-
MDA and JSF by Lofi Dewanto on March 04 2004 01:15 EST
- JSF code generation from UML by Fred Madiot on April 28 2005 12:54 EDT
-
MDA and JSF by Henrique Steckelberg on March 04 2004 12:43 EST
-
Welcome to the most complex (xxx)ML programming language! by Jason Carreira on March 04 2004 01:06 EST
-
Welcome to the most complex (xxx)ML programming language! by Henrique Steckelberg on March 04 2004 01:22 EST
- Welcome to the most complex (xxx)ML programming language! by Konstantin Ignatyev on March 04 2004 02:46 EST
- Welcome to the most complex (xxx)ML programming language! by Jason Carreira on March 05 2004 02:05 EST
-
Welcome to the most complex (xxx)ML programming language! by Henrique Steckelberg on March 04 2004 01:22 EST
-
MDA and JSF by Lofi Dewanto on March 04 2004 12:05 EST
-
Welcome to the most complex (xxx)ML programming language! by Henrique Steckelberg on March 04 2004 11:26 EST
-
Welcome to the most complex (xxx)ML programming language! by Lofi Dewanto on March 04 2004 10:57 EST
- Welcome to the most complex (xxx)ML programming language! by John Brand on March 04 2004 10:11 EST
-
Exactly the same! by Lofi Dewanto on March 04 2004 10:48 EST
-
Is JSF replacement for Struts. by Nagsen Chankapure on March 04 2004 11:07 EST
-
Is JSF replacement for Struts. by Henrique Steckelberg on March 04 2004 12:04 EST
-
Is JSF replacement for Struts. by Dmitry Namiot on March 04 2004 01:53 EST
- Is JSF replacement for Struts. by Henrique Steckelberg on March 04 2004 02:09 EST
-
Is JSF replacement for Struts. by Dmitry Namiot on March 04 2004 01:53 EST
-
Is JSF replacement for Struts. by Henrique Steckelberg on March 04 2004 12:04 EST
- Exactly the same! by John Brand on March 04 2004 11:28 EST
-
Is JSF replacement for Struts. by Nagsen Chankapure on March 04 2004 11:07 EST
-
Exactly the same! by Lofi Dewanto on March 04 2004 10:48 EST
- Welcome to the most complex (xxx)ML programming language! by Dmitry Namiot on March 04 2004 10:30 EST
- Welcome to the most complex (xxx)ML programming language! by Henrique Steckelberg on March 04 2004 09:58 EST
- JCP Releases JavaServer Faces 1.0 by Jon Tirsen on March 04 2004 05:07 EST
- JCP Releases JavaServer Faces 1.0 by Henrique Steckelberg on March 04 2004 09:46 EST
-
JCP Releases JavaServer Faces 1.0 by Dmitry Namiot on March 04 2004 11:16 EST
-
JCP Releases JavaServer Faces 1.0 by Henrique Steckelberg on March 04 2004 11:53 EST
-
JCP Releases JavaServer Faces 1.0 by Jason Carreira on March 04 2004 01:09 EST
- JCP Releases JavaServer Faces 1.0 by Henrique Steckelberg on March 04 2004 01:49 EST
-
JCP Releases JavaServer Faces 1.0 by Jason Carreira on March 04 2004 01:09 EST
-
JCP Releases JavaServer Faces 1.0 by Henrique Steckelberg on March 04 2004 11:53 EST
-
overlap with struts? by joost de vries on March 04 2004 12:49 EST
- overlap with struts? by Henrique Steckelberg on March 04 2004 03:56 EST
-
JCP Releases JavaServer Faces 1.0 by Dmitry Namiot on March 04 2004 11:16 EST
- JCP Releases JavaServer Faces 1.0 by Henrique Steckelberg on March 04 2004 09:46 EST
- Hurray, Model 2 again by Karl Banke on March 04 2004 10:07 EST
- Macromedia and JSF by Sean Sullivan on March 04 2004 14:26 EST
- Macromedia and JSF by Vic Cekvenich on March 06 2004 11:47 EST
- JCP Releases JavaServer Faces 1.0 by no name on March 04 2004 15:17 EST
- JCP Releases JavaServer Faces 1.0 by Konstantin Ignatyev on March 04 2004 15:43 EST
- JCP Releases JavaServer Faces 1.0 by no name on March 05 2004 01:25 EST
- JCP Releases JavaServer Faces 1.0 by Wouter Zoons on March 04 2004 19:04 EST
- Or just use myeclipseide by brtan dfsafad on March 04 2004 07:13 EST
-
JCP Releases JavaServer Faces 1.0 by no name on March 05 2004 01:17 EST
- JCP Releases JavaServer Faces 1.0 by Wouter Zoons on March 05 2004 04:39 EST
- JCP Releases JavaServer Faces 1.0 by Konstantin Ignatyev on March 04 2004 15:43 EST
- JSF vs. BarracudaMVC by Lofi Dewanto on March 04 2004 16:20 EST
- JSF vs. BarracudaMVC by Henrique Steckelberg on March 04 2004 20:46 EST
- JSF vs. BarracudaMVC by Henrique Steckelberg on March 04 2004 21:32 EST
- Why I hate BarracudaMVC by Emmanuel Sackey on March 05 2004 04:28 EST
- Actually I think JSF is wonderful by Karim Saloojee on March 05 2004 03:38 EST
- Actually I think JSF is wonderful by Dmitry Namiot on March 05 2004 04:07 EST
- Actually I think JSF is wonderful by Jason Carreira on March 05 2004 10:07 EST
- Actually I think JSF is wonderful by Henrique Steckelberg on March 05 2004 11:18 EST
- Actually I think JSF is wonderful by jeff smith on March 15 2004 19:57 EST
-
Granularity of Components[ Go to top ]
- Posted by: random fletch
- Posted on: March 03 2004 17:28 EST
- in response to Kito Mann
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. -
JSF vs Nukes[ Go to top ]
- Posted by: Andrew Oliver
- Posted on: March 03 2004 19:05 EST
- in response to random fletch
It sounds like what you need is Nukes more than JSF. check it out: http://jboss.org/developers/projects/nukes/index -
JSF Forum[ Go to top ]
- Posted by: Sergey Smirnov
- Posted on: March 03 2004 23:18 EST
- in response to Andrew Oliver
It looks like this thread becomes a good place for advertising.
This is my two cents:
JavaServer Faces Technology Developer Forum. -
JSF vs Nukes[ Go to top ]
- Posted by: Marina Prikaschikova
- Posted on: March 04 2004 08:21 EST
- in response to Andrew Oliver
and check out JSOS as well:
http://www.servletsuite.com/servlets.htm -
There is mvnForum, opensource Jsp/Servlet forum[ Go to top ]
- Posted by: Minh Nguyen
- Posted on: March 03 2004 23:00 EST
- in response to random fletch
Hello Random Fetch and members of TSS,
If you are looking for a good, rich feature Java/Jsp/Servlet forum, then try mvnForum at http://www.mvnForum.com . This project is mature and very stable although it is still in RC development phrase. I hope to release the final mvnForum 1.0 GA soon and considering porting mvnForum to JSF in the near future.
For the current feature please visit http://www.mvnforum.com/mvnforumweb/feature.jsp
To download mvnForum now, please visit http://www.mvnforum.com/mvnforumweb/download.jsp
Thanks and I hope you will enjoy mvnForum ;)
Minh Nguyen
mvnForum Developer
http://www.mvnforum.com
MyVietnam Group
http://www.MyVietnam.net -
JSF Components[ Go to top ]
- Posted by: John Webber
- Posted on: March 05 2004 08:36 EST
- in response to random fletch
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. -
WebGalileo Faces 1.0 Java web components are available[ Go to top ]
- Posted by: John Webber
- Posted on: June 01 2004 07:14 EDT
- in response to John Webber
WebGalileo Faces 1.0(Java Web Components with full support of Sun
Java Server Faces specification) sales were launched.
Thanks.
http://www.javawebcomponents.com -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: March 04 2004 04:04 EST
- in response to Kito Mann
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? -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 09:58 EST
- in response to Lofi Dewanto
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 -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: March 04 2004 10:57 EST
- in response to Henrique Steckelberg
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. -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 11:26 EST
- in response to Lofi Dewanto
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. -
MDA and JSF[ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: March 04 2004 12:05 EST
- in response to Henrique Steckelberg
<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 <- 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. -
MDA and JSF[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 12:43 EST
- in response to Lofi Dewanto
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 -
MDA and JSF[ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: March 04 2004 13:15 EST
- in response to Henrique Steckelberg
<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. -
MDA and JSF[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 14:04 EST
- in response to Lofi Dewanto
<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 -
MDA and JSF[ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: March 04 2004 15:46 EST
- in response to Henrique Steckelberg
<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. -
JSF code generation from UML[ Go to top ]
- Posted by: Fred Madiot
- Posted on: April 28 2005 12:54 EDT
- in response to Lofi Dewanto
Lofi,
if you are interested by MDA solutions to generate JSF code from UML models, just have a look at http://www.mia-software.com/index.php?lang=en&theme=sol-boosters-j2ee-jsf">Mia-Software's JSF Generator</a>.
It generates forms and actions from a very simple UML model (from any UML modeler) where you just have to describe navigation through actions and views and data hosted by these views.
In addition, with the same model, you can also generate code for Struts with http://www.mia-software.com/index.php?lang=en&theme=sol-boosters-j2ee-struts">Mia-Software's Struts Generator</a>.
If the generated code doesn't suit to you, you can change the templates to customize the generator to your own needs.
Fred -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Jason Carreira
- Posted on: March 04 2004 13:06 EST
- in response to Henrique Steckelberg
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 -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 13:22 EST
- in response to Jason Carreira
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 -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: March 04 2004 14:46 EST
- in response to Henrique Steckelberg
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. -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Jason Carreira
- Posted on: March 05 2004 02:05 EST
- in response to Henrique Steckelberg
> 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. -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: John Brand
- Posted on: March 04 2004 10:11 EST
- in response to Lofi Dewanto
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 -
Exactly the same![ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: March 04 2004 10:48 EST
- in response to John Brand
<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. -
Is JSF replacement for Struts.[ Go to top ]
- Posted by: Nagsen Chankapure
- Posted on: March 04 2004 11:07 EST
- in response to Lofi Dewanto
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? -
Is JSF replacement for Struts.[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 12:04 EST
- in response to Nagsen Chankapure
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. -
Is JSF replacement for Struts.[ Go to top ]
- Posted by: Dmitry Namiot
- Posted on: March 04 2004 13:53 EST
- in response to Henrique Steckelberg
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 -
Is JSF replacement for Struts.[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 14:09 EST
- in response to Dmitry Namiot
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 -
Exactly the same![ Go to top ]
- Posted by: John Brand
- Posted on: March 04 2004 11:28 EST
- in response to Lofi Dewanto
<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. -
Welcome to the most complex (xxx)ML programming language![ Go to top ]
- Posted by: Dmitry Namiot
- Posted on: March 04 2004 10:30 EST
- in response to Lofi Dewanto
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 -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Jon Tirsen
- Posted on: March 04 2004 05:07 EST
- in response to Kito Mann
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. -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 09:46 EST
- in response to Jon Tirsen
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 -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Dmitry Namiot
- Posted on: March 04 2004 11:16 EST
- in response to Henrique Steckelberg
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 -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 11:53 EST
- in response to Dmitry Namiot
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 -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Jason Carreira
- Posted on: March 04 2004 13:09 EST
- in response to Henrique Steckelberg
> 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. -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 13:49 EST
- in response to Jason Carreira
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 -
overlap with struts?[ Go to top ]
- Posted by: joost de vries
- Posted on: March 04 2004 12:49 EST
- in response to Henrique Steckelberg
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 -
overlap with struts?[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 15:56 EST
- in response to joost de vries
A very nice discussion about Structs-JSF integration:
http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsMoreAboutJSF
Answers all the whys and hows of it... ;)
Regards,
Henrique Steckelberg -
Hurray, Model 2 again[ Go to top ]
- Posted by: Karl Banke
- Posted on: March 04 2004 10:07 EST
- in response to Kito Mann
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! -
Macromedia and JSF[ Go to top ]
- Posted by: Sean Sullivan
- Posted on: March 04 2004 14:26 EST
- in response to Kito Mann
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 -
Macromedia and JSF[ Go to top ]
- Posted by: Vic Cekvenich
- Posted on: March 06 2004 11:47 EST
- in response to Sean Sullivan
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. -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: no name
- Posted on: March 04 2004 15:17 EST
- in response to Kito Mann
Honestly guys, do you really believe that the "page-oriented, server-compiled" document is the future of the presentation layer? I doubt it...
Ovi -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Konstantin Ignatyev
- Posted on: March 04 2004 15:43 EST
- in response to no name
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. -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: no name
- Posted on: March 05 2004 01:25 EST
- in response to Konstantin Ignatyev
I actually just waiting when X-Window server will be standard on clients. I am serious.
Here's the first step: http://www.jcraft.com/weirdx/ -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Wouter Zoons
- Posted on: March 04 2004 19:04 EST
- in response to no name
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 at lists dot sourceforge dot 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. -
Or just use myeclipseide[ Go to top ]
- Posted by: brtan dfsafad
- Posted on: March 04 2004 19:13 EST
- in response to Wouter Zoons
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 -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: no name
- Posted on: March 05 2004 01:17 EST
- in response to Wouter Zoons
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 -
JCP Releases JavaServer Faces 1.0[ Go to top ]
- Posted by: Wouter Zoons
- Posted on: March 05 2004 04:39 EST
- in response to no name
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. -
JSF vs. BarracudaMVC[ Go to top ]
- Posted by: Lofi Dewanto
- Posted on: March 04 2004 16:20 EST
- in response to Kito Mann
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. -
JSF vs. BarracudaMVC[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 20:46 EST
- in response to Lofi Dewanto
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 -
JSF vs. BarracudaMVC[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 04 2004 21:32 EST
- in response to Lofi Dewanto
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 -
Why I hate BarracudaMVC[ Go to top ]
- Posted by: Emmanuel Sackey
- Posted on: March 05 2004 04:28 EST
- in response to Lofi Dewanto
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 -
Actually I think JSF is wonderful[ Go to top ]
- Posted by: Karim Saloojee
- Posted on: March 05 2004 03:38 EST
- in response to Kito Mann
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 -
Actually I think JSF is wonderful[ Go to top ]
- Posted by: Dmitry Namiot
- Posted on: March 05 2004 04:07 EST
- in response to Karim Saloojee
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 -
Actually I think JSF is wonderful[ Go to top ]
- Posted by: Jason Carreira
- Posted on: March 05 2004 10:07 EST
- in response to Karim Saloojee
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? -
Actually I think JSF is wonderful[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: March 05 2004 11:18 EST
- in response to Jason Carreira
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? -
Actually I think JSF is wonderful[ Go to top ]
- Posted by: jeff smith
- Posted on: March 15 2004 19:57 EST
- in response to Karim Saloojee
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