The public draft of the JavaServer Faces 1.0 Specification has been published today, as well as an early access download of the API's and tag library. JSF is a web application framework that reduces the amount of code needed to write a web front end. Developers need only write JSF components and corresponding event handling code, the framework then simplifies the tasks of validation, request parameter parsing, state management, multipe clients support, etc.
Download the Spec and Early Access here: http://java.sun.com/j2ee/javaserverfaces
Check out TSS' Hard Core Tech Talk Interview with Amy Fowler, Former JSF Spec Lead
-
Java Server Faces Public Draft and Early Access Available (118 messages)
- Posted by: Floyd Marinescu
- Posted on: August 30 2002 11:40 EDT
Threaded Messages (118)
- Java Server Faces Public Draft and Early Access Available by Suraj Kumar on August 30 2002 13:58 EDT
- Java Server Faces Public Draft and Early Access Available by Bruno CHEVALIER on September 05 2002 03:52 EDT
-
Java Server Faces Public Draft and Early Access Available by Carlos Roberto Vieira da Silva on September 05 2002 08:47 EDT
- Java Server Faces Public Draft and Early Access Available by Carlos Roberto Vieira da Silva on September 05 2002 08:53 EDT
-
Java Server Faces Public Draft and Early Access Available by Carlos Roberto Vieira da Silva on September 05 2002 08:47 EDT
- Java Server Faces Public Draft and Early Access Available by Bruno CHEVALIER on September 05 2002 03:52 EDT
- Java Server Faces Public Draft and Early Access Available by Robin Sharp on August 30 2002 17:57 EDT
- Java Server Faces Public Draft and Early Access Available by Jochen Krause on August 30 2002 18:43 EDT
-
But is JSF component based? by Howard Lewis Ship on August 30 2002 07:50 EDT
-
But is JSF component based? by Aapo Laakkonen on August 30 2002 09:22 EDT
- Tapestry Postings by Howard Lewis Ship on August 30 2002 10:34 EDT
-
But is JSF component based? by Rickard Oberg on September 01 2002 04:26 EDT
- Porlet API by Howard Lewis Ship on September 01 2002 04:51 EDT
-
But is JSF component based? by Aapo Laakkonen on August 30 2002 09:22 EDT
- Java Server Faces Public Draft and Early Access Available by Adam Greene on August 31 2002 10:43 EDT
- Java Server Faces Public Draft and Early Access Available by Adam Greene on August 31 2002 10:44 EDT
-
But is JSF component based? by Howard Lewis Ship on August 30 2002 07:50 EDT
- Java Server Faces Public Draft and Early Access Available by Borislav Iordanov on August 31 2002 00:56 EDT
-
Java Server Faces Public Draft and Early Access Available by Mark Allerton on August 31 2002 03:56 EDT
-
Java Server Faces Public Draft and Early Access Available by Carlos Perez on August 31 2002 07:38 EDT
-
Java Server Faces Public Draft and Early Access Available by Reuben Cleetus on August 31 2002 10:14 EDT
- Java Server Faces Public Draft and Early Access Available by Dan Dubinsky on September 01 2002 08:33 EDT
-
Java Server Faces Public Draft and Early Access Available by Reuben Cleetus on August 31 2002 10:14 EDT
-
Java Server Faces Public Draft and Early Access Available by Carlos Perez on August 31 2002 07:38 EDT
- Java Server Faces Public Draft and Early Access Available by Howard Lewis Ship on August 31 2002 12:41 EDT
-
Java Server Faces Public Draft and Early Access Available by Mark Allerton on August 31 2002 03:56 EDT
- Java Server Faces Public Draft and Early Access Available by Prakash Anthony on September 01 2002 11:39 EDT
- Java Server Faces Public Draft and Early Access Available by Mike Joslyn on September 03 2002 09:30 EDT
-
Java Server Faces Public Draft and Early Access Available by Stefan Mischook on September 03 2002 11:06 EDT
-
Java Server Faces Public Draft and Early Access Available by Reuben Cleetus on September 03 2002 11:41 EDT
-
Java Server Faces Public Draft and Early Access Available by Mark Lesk on September 03 2002 02:08 EDT
-
Java Server Faces Public Draft and Early Access Available by Stefan Mischook on September 03 2002 06:30 EDT
-
Java Server Faces Public Draft and Early Access Available by Borislav Iordanov on September 03 2002 07:52 EDT
-
Java Server Faces Public Draft and Early Access Available by Pete Cassetta on September 04 2002 10:48 EDT
- Java Server Faces Public Draft and Early Access Available by Borislav Iordanov on September 05 2002 05:46 EDT
-
Java Server Faces Public Draft and Early Access Available by Pete Cassetta on September 04 2002 10:48 EDT
- Java Server Faces Public Draft and Early Access Available by Fred Cahill on September 03 2002 07:54 EDT
-
Java Server Faces Public Draft and Early Access Available by Borislav Iordanov on September 03 2002 07:52 EDT
-
Java Server Faces Public Draft and Early Access Available by Stefan Mischook on September 03 2002 06:30 EDT
-
Java Server Faces Public Draft and Early Access Available by Mark Lesk on September 03 2002 02:08 EDT
-
Java Server Faces Public Draft and Early Access Available by Reuben Cleetus on September 03 2002 11:41 EDT
-
Java Server Faces Public Draft and Early Access Available by Stefan Mischook on September 03 2002 11:06 EDT
- Java Server Faces Public Draft and Early Access Available by Jochen Krause on August 30 2002 18:43 EDT
- Java Server Faces Public Draft and Early Access Available by Jon Tirsen on August 31 2002 03:09 EDT
- Java Server Faces Public Draft and Early Access Available by Dmitry Namiot on September 02 2002 09:58 EDT
- Java Server Faces Public Draft and Early Access Available by Vic Cekvenich on August 31 2002 07:28 EDT
- THE CRAPPIEST AND RIDICULOUS SPECIFICATION OF SUN by pierre loire on August 31 2002 13:22 EDT
- Java Server Faces Public Draft and Early Access Available by Igor Zavialov on August 31 2002 14:19 EDT
-
Java Server Faces Public Draft and Early Access Available by pierre loire on August 31 2002 05:13 EDT
-
Java Server Faces Public Draft and Early Access Available by Reuben Cleetus on August 31 2002 11:02 EDT
- Java Server Faces Public Draft and Early Access Available by eric larson on September 08 2002 07:39 EDT
-
Java Server Faces Public Draft and Early Access Available by Igor Zavialov on August 31 2002 11:49 EDT
- Java Server Faces Public Draft and Early Access Available by Chad Johnson on September 01 2002 01:12 EDT
-
Java Server Faces Public Draft and Early Access Available by Reuben Cleetus on August 31 2002 11:02 EDT
-
Java Server Faces Public Draft and Early Access Available by pierre loire on August 31 2002 05:13 EDT
- Java Server Faces Public Draft and Early Access Available by Igor Zavialov on August 31 2002 14:19 EDT
- Java Server Faces Public Draft and Early Access Available by Clifford Cheng on August 31 2002 17:15 EDT
- Java Server Faces Public Draft and Early Access Available by Chad Johnson on September 01 2002 13:26 EDT
- Java Server Faces Public Draft and Early Access Available by Robin Sharp on September 01 2002 14:12 EDT
-
Java Server Faces Public Draft and Early Access Available by Chad Johnson on September 01 2002 02:51 EDT
- Java Server Faces Public Draft and Early Access Available by Robin Sharp on September 01 2002 03:28 EDT
-
Java Server Faces Public Draft and Early Access Available by Dan Dubinsky on September 01 2002 06:02 EDT
-
Java Server Faces Public Draft and Early Access Available by Chad Johnson on September 01 2002 07:07 EDT
-
Java Server Faces Public Draft and Early Access Available by Howard Lewis Ship on September 01 2002 09:10 EDT
-
Java Server Faces Public Draft and Early Access Available by Chad Johnson on September 01 2002 10:10 EDT
-
Java Server Faces Public Draft and Early Access Available by Howard Lewis Ship on September 01 2002 11:12 EDT
-
Java Server Faces Public Draft and Early Access Available by Christian Sell on September 02 2002 03:31 EDT
- Java Server Faces Public Draft and Early Access Available by Andrew Harris on September 02 2002 04:38 EDT
-
The Problem with Tapestry... by Carlos Perez on September 02 2002 09:08 EDT
-
The Problem with Tapestry... by Howard Lewis Ship on September 02 2002 09:52 EDT
- The Problem with Tapestry... by Howard Lewis Ship on September 02 2002 11:04 EDT
-
Tapestry with JSP by Howard Lewis Ship on September 03 2002 07:20 EDT
- Tapestry with JSP by Mark Lesk on September 03 2002 09:18 EDT
-
Tapestry with JSP by Carlos Perez on September 03 2002 10:33 EDT
-
Tapestry with JSP by Jonathan Asbell on September 09 2002 12:18 EDT
-
Tapestry with JSP by Howard Lewis Ship on September 09 2002 07:21 EDT
-
Tapestry install problems by Jonathan Asbell on September 09 2002 12:48 EDT
- Tapestry install problems by Howard Lewis Ship on September 09 2002 01:02 EDT
-
Tapestry install problems by Jonathan Asbell on September 09 2002 12:48 EDT
- Tapestry -- Getting Right JBoss Version by Howard Lewis Ship on September 09 2002 01:19 EDT
-
Tapestry with JSP by Howard Lewis Ship on September 09 2002 07:21 EDT
-
Tapestry with JSP by Jonathan Asbell on September 09 2002 12:18 EDT
-
Tapestry with JSP by Clifford Cheng on September 03 2002 11:39 EDT
- No capable leaders by Ignat Skoryh on September 04 2002 12:52 EDT
-
Tapestry with JSP by Pete Cassetta on September 04 2002 10:55 EDT
-
Tapestry with JSP by Howard Lewis Ship on September 05 2002 09:13 EDT
-
Tapestry with JSP by Carlos Perez on September 05 2002 10:35 EDT
- Tapestry with JSP by Howard Lewis Ship on September 05 2002 10:52 EDT
-
Tapestry with JSP by Malcolm Edgar on September 05 2002 08:57 EDT
- Tapestry with JSP by Borislav Iordanov on September 05 2002 09:45 EDT
-
Tapestry with JSP by Carlos Perez on September 05 2002 10:35 EDT
-
Tapestry with JSP by Howard Lewis Ship on September 05 2002 09:13 EDT
-
No Problem with Tapestry... by bill salamanca on September 09 2002 01:48 EDT
-
No Problem with Tapestry... by Howard Lewis Ship on September 09 2002 07:28 EDT
-
No Problem with Tapestry... by Stu Charlton on September 09 2002 10:35 EDT
- Tapestry thread by Howard Lewis Ship on September 09 2002 01:05 EDT
- No Problem with Tapestry... by Stefan Mischook on September 09 2002 04:25 EDT
-
No Problem with Tapestry... by Stu Charlton on September 09 2002 10:35 EDT
-
No Problem with Tapestry... by Howard Lewis Ship on September 09 2002 07:28 EDT
-
The Problem with Tapestry... by Howard Lewis Ship on September 02 2002 09:52 EDT
-
Java Server Faces Public Draft and Early Access Available by Christian Sell on September 02 2002 03:31 EDT
-
Java Server Faces Public Draft and Early Access Available by Howard Lewis Ship on September 01 2002 11:12 EDT
-
Java Server Faces Public Draft and Early Access Available by Chad Johnson on September 01 2002 10:10 EDT
- Java Server Faces Public Draft and Early Access Available by Dan Dubinsky on September 01 2002 10:21 EDT
-
Java Server Faces Public Draft and Early Access Available by Howard Lewis Ship on September 01 2002 09:10 EDT
-
Java Server Faces Public Draft and Early Access Available by Chad Johnson on September 01 2002 07:07 EDT
-
Java Server Faces Public Draft and Early Access Available by Chad Johnson on September 01 2002 02:51 EDT
- Problems with JSF by Howard Lewis Ship on September 01 2002 17:02 EDT
- Java Server Faces Public Draft and Early Access Available by Robin Sharp on September 01 2002 14:12 EDT
- Java Server Faces Public Draft and Early Access Available by Smythe on September 02 2002 04:53 EDT
- Java Server Faces Public Draft and Early Access Available by Carlos Perez on September 02 2002 08:34 EDT
- Java Server Faces Public Draft and Early Access Available by Reuben Cleetus on September 02 2002 09:48 EDT
- Java Server Faces Public Draft and Early Access Available by Dmitry Namiot on September 02 2002 10:17 EDT
-
Java Server Faces Public Draft and Early Access Available by Bill Willis on September 02 2002 09:04 EDT
- Java Server Faces Public Draft and Early Access Available by Borislav Iordanov on September 02 2002 10:55 EDT
- Java Server Faces Public Draft and Early Access Available by Dan Dubinsky on September 03 2002 08:28 EDT
- Java Server Faces Public Draft and Early Access Available by Clifford Cheng on September 03 2002 05:17 EDT
- SOMEONE ASKED ABOUT HOW JSF COMPARES TO .NET ??? by Jonathan Asbell on September 02 2002 11:11 EDT
- SilverStream had Web Components with IDE Integration YEARS ago by Michael McCutcheon on September 03 2002 00:46 EDT
- And dont forget Apple WebObjects by Christian Sell on September 03 2002 03:49 EDT
- Java Server Faces Public Draft and Early Access Available by Slava Imeshev on September 04 2002 19:37 EDT
- Java Server Faces Public Draft and Early Access Available by Pete Cassetta on September 04 2002 22:50 EDT
- Java Server Faces Public Draft and Early Access Available by Slava Imeshev on September 06 2002 07:10 EDT
- Java Server Faces Public Draft and Early Access Available by Borislav Iordanov on September 05 2002 05:52 EDT
- Java Server Faces Public Draft and Early Access Available by Dan Holmsand on September 05 2002 08:39 EDT
- Java Server Faces Public Draft and Early Access Available by Pete Cassetta on September 04 2002 22:50 EDT
- Java Server Faces Public Draft and Early Access Available by no name on September 05 2002 12:18 EDT
- Wings (to fly with) by vinay soni on September 05 2002 15:04 EDT
- some reality checks by Stu Charlton on September 05 2002 16:30 EDT
- some reality checks by Stefan Mischook on September 05 2002 20:09 EDT
-
some reality checks (.NET) by Pete Cassetta on September 06 2002 12:47 EDT
- some reality checks (.NET) by Stefan Mischook on September 06 2002 02:22 EDT
- some reality checks (.NET) by Stefan Mischook on September 06 2002 02:32 EDT
-
some reality checks (.NET) by Reuben Cleetus on September 06 2002 09:21 EDT
-
some reality checks (.NET) by Eugene Bloss on September 06 2002 12:45 EDT
- JSF and Sun by Arjuna Chala on September 06 2002 02:35 EDT
- some reality checks (.NET) by Pete Cassetta on September 06 2002 01:11 EDT
- some reality checks (.NET) by Stu Charlton on September 08 2002 05:06 EDT
-
some reality checks (.NET) by Eugene Bloss on September 06 2002 12:45 EDT
- More on WebObjects by Stu Charlton on September 08 2002 05:03 EDT
-
some reality checks (.NET) by Pete Cassetta on September 06 2002 12:47 EDT
- some reality checks - er by Robin Sharp on September 08 2002 04:56 EDT
-
Reaction to JSF hype by Howard Lewis Ship on September 08 2002 10:35 EDT
- Reaction to JSF hype by Stu Charlton on September 08 2002 04:49 EDT
-
Reaction to JSF hype by Howard Lewis Ship on September 08 2002 10:35 EDT
- some reality checks by Stefan Mischook on September 05 2002 20:09 EDT
- Java Server Faces Public Draft and Early Access Available by Ivelin Ivanov on September 07 2002 22:16 EDT
- My JSF critique by Stu Charlton on September 08 2002 17:41 EDT
- THE GOOD OLD GUI FRAMEWORK TOPIC by Robert Stindl on September 12 2002 10:53 EDT
- THE GOOD OLD GUI FRAMEWORK TOPIC by Sankar B on September 16 2002 09:39 EDT
- THE GOOD OLD GUI FRAMEWORK TOPIC by Jochen Krause on September 20 2002 12:11 EDT
- THE GOOD OLD GUI FRAMEWORK TOPIC by Sankar B on September 16 2002 09:39 EDT
- Java Server Faces Public Draft and Early Access Available by Vic Cekvenich on September 17 2002 22:25 EDT
- Java Server Faces Public Draft and Early Access Available by Sankar B on September 18 2002 04:48 EDT
- Java Server Faces Public Draft and Early Access Available by Vic Cekvenich on September 18 2002 05:13 EDT
- Java Server Faces Public Draft and Early Access Available by Sankar B on September 18 2002 04:48 EDT
- Java Server Faces Public Draft and Early Access Available by jp fielding on September 22 2002 10:26 EDT
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Suraj Kumar
- Posted on: August 30 2002 13:58 EDT
- in response to Floyd Marinescu
Where can we find more documentation on JSF? -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Bruno CHEVALIER
- Posted on: September 05 2002 03:52 EDT
- in response to Suraj Kumar
Have you downloaded the java server faces tutorial?
It's a 53 pages pdf. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Carlos Roberto Vieira da Silva
- Posted on: September 05 2002 08:47 EDT
- in response to Bruno CHEVALIER
I only know the online. Where's the PDF? -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Carlos Roberto Vieira da Silva
- Posted on: September 05 2002 08:53 EDT
- in response to Carlos Roberto Vieira da Silva
Reply to myself :-P Sorry. I just follow to TOC of the JSF on-line tutorial and was there "How to print this..." went to the PDF file... -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Robin Sharp
- Posted on: August 30 2002 17:57 EDT
- in response to Floyd Marinescu
I've been looking forward to the relase of JFC for 2 years now. As soon I down loaded the PDF I was all set to get a buzz from the pretty pictures of Trees, Pop-up Menus, Split panes.
So I scrolled through chapter 4 on Standard User Interface Components ... and I scrolled, past the text field, radio buttons ... and I scrolled ... Hey chapter 5, what happened to the tables, trees, menus, split panes ?
May be I missed something. Perhaps chapter 5 was where it got serious. No. I looked back at the index, search the pdf. Then it dawned on me.
I've waited 2 years for this! It's just form components. No tables. No trees. No menus. No swapable look and feels to PDF/XML/JFC. No nice chunky demos to rub the .NET'ers faces in. Basically no beef.
If anybody was hoping for Sun to provide a competitor to the .NET Web Components they're going to be let down.
We wrote a product called http://www.swinglets.com/swinglets three years ago, and frankly we were hoping Sun would do a good job at replacing it. Sadly not.
The thought going through my mind is, have Sun acted irresponsibly promoting Java Faces as a web component tool kit, when it turns out to be Html Form event handlers?
I've just got back from a chinese meal (nice) and a few pints and I feel just the same as when I wrote this post this afternoon. 2 years ago this would have been news. It's now going to be a case of how work to around this API rather than show it off. After several pints I believe that Sun intended us to render an ObjectSelection as a Tree rather than a Combo.
Ho hum. I guess with Sun's share price being so low they have to cut back on their API's now. Sorry can't afford to spec Tree's and Table's folks.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Jochen Krause
- Posted on: August 30 2002 18:43 EDT
- in response to Robin Sharp
JSF is a very important step towards easier web application development. Even if currently nobody seems to be extremly exited about JSF, we should take into account that Java Server Faces is still at draft level, so for the final release and coming releases there are opportunities to improve it.
Send them feedback about what you miss in the spec and where you see room for improvements. This is how the community should hopefully work!
But the spec is bringing up the same old question about the right sequence of innovation and standardization. The Expert group for JSF is quite large (about 50 members) and integrates most of the major players in the Java Community. It seems that many ideas and opinions had to be considered, which is good in terms of a sound spec, but as as well a disadvantage in terms of getting the spec final. Maybe it was the pressure to get at least anything out that lead to the very basic set of components.
Nevertheless we need a standard, nobody is going to profit from 20 or 50 frameworks scattered in the world with hardly anything in common. So we shouldn't wine about what we are missing from framework A or framework b, but try to use JSF as a basis and improve it or extend it.
Component based development is a big chance for web app development, especially for creating rich user interfaces (e.g. demos on w4toolkit.com).
This is a huge market and we shouldn't leave it to asp.net. -
But is JSF component based?[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: August 30 2002 19:50 EDT
- in response to Jochen Krause
Based on what I've seen JSF is not a component framework, its a tag framework. It has the ability to represent the tags on a page as a hierarchy of objects but its missing a lot of the features I'd expect of a component framework (i.e., stuff I built into Tapestry).
I don't see a way to build complex components from simple components.
Components don't have a clear API. Tapestry components have a clear, declared, type-safe (yet completely dynamic) API.
You can't package a component with all the resources it needs. For example, if a component needs a particular image or stylesheet, or if it needs to render a page (JSP) in a popup window ... there's no way to do that. Tapestry has always supported private assets (resources on the classpath that are exported as needed) and taken care of all that behind the scenes. With 2.2 (now in beta) you can package a set of components as a library, and include pages, resources and even Tapestry services.
I didn't see much support for client-side scripting. Tapestry has an elegant mechanism that not only puts all client-side scripting in one place (just before the <body> tag, regardless of which component creates the JavaScript where on the page) ... but also has a specialized templating language just for generating JavaScript that takes care of the dynamic nature of Tapestry (that is, that forms and form elements are named by the framework, not the developer).
Tapestry is also uniquely positioned for RAD tool development. First, the split between HTML, XML specification and Java code is a much simpler environment for RAD. The Tapestry specification DTD includes a meta-data tag (<property>) on all key elements ... RAD tools can record whatever meta-data they want there (and Tapestry simply ignores it).
In addition, much of the behavior of a Tapestry page or component can be expressed in terms of OGNL expressions (http://www.ognl.org) or in terms of re-usable beans ... not just Java code. Again, that means more of the behavior can be defined in declarative XML rather than in Java code, which improves round-trip engineering.
I think we've got a case of one passionate developer with experience and a clear vision (plus a growing community of assistant developers) vs. a big-ass committee.
Back a winner. Use Tapestry.
http://tapestry.sf.net
-
But is JSF component based?[ Go to top ]
- Posted by: Aapo Laakkonen
- Posted on: August 30 2002 21:22 EDT
- in response to Howard Lewis Ship
Howard,
I was wondering that are you going to promote Tapestry here also as you have done in almost every web-related news postings. Yes, we all know that Tapestry is the web component framework silver bullet that everyone has to use or at least try.
I don't personally believe in silver bullets. What I'd like to know is the worse sides of Tapestry. What are the other frameworks (e.g. WebWork) doing better compared to Tapestry? I know that there is some wafer project or something like it that tries to compare these frameworks, but I have not yet found anything useful from there.
> I think we've got a case of one passionate
> developer with experience and a clear vision
That might be true, but you should remember that not everybody shares your vision. Personally I find it annoying that you advertise your framework and same time bash the other players out there. Why aren't you co-operating with JCP for example? -
Tapestry Postings[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: August 30 2002 22:34 EDT
- in response to Aapo Laakkonen
I don't believe in silver bullets either. Tapestry is not a silver bullet ... it's not going to allow trained monkeys to generated enterprise web applications. Then again, nothing will.
Tapestry is simply the right tool for the job.
The JCP is not interested in individual contributors. Check the recent logs (the ones around that JSF interview) ... the JCP is not interested in outside help, even from groups that have created commercial products (such as Swinglets). It's just a marketing ploy to gain the air of acceptance.
Exactly, what is this bashing you are talking about? When Tapestry comes up in a thread, I'll join in to answer peoples questions about Tapestry. That's the point of an open forum. You should see some of the posts right now on JavaLobby ... people have used the word "lynch" in reference to the crew that put together JSF.
In answer to your question about Tapestry's weaknesses; here they are as I understand them:
1) Documentation is still too thin. A community-driven effort to write a new and better tutorial is under way.
2) Unlike WebWork, Tapestry is fairly wedded to the web application request cycle. WebWork has additional layers of abstraction that allow view control logic to be used without concern for the environment ... so the same logic can be wedded to a web app or a Swing GUI.
3) More and more sophisticated components; more components like the Palette that really push the limits (with a significant client-side aspect).
4) There's a constant murmur for Tapestry components operating inside JSPs as a taglib.
Basically, #1 and #3 are whats between Tapestry 2.2-beta-1 and Tapestry-2.2 (GA).
#4 is a tremendous challenge; the servlet/JSP model and the Tapestry model are that divergent. I pursuing, for my day job, a cleaner integration between servlets/Struts/JSPs and Tapestry that would allow existing applications to migrate into Tapestry piecewise.
#2 is a matter of taste; I believe that reuse occurs in the application layer (i.e., EJBs or the equivalent) not in the presentation layer. In the many projects I've worked on, the biggest win is to reduce and manage the complexity of the presentation layer (generally, the application layers are much more straight forward) ... that's what Tapestry does, but it accomplishes so much by being "wedded" to the web application request cycle.
-
But is JSF component based?[ Go to top ]
- Posted by: Rickard Oberg
- Posted on: September 01 2002 16:26 EDT
- in response to Howard Lewis Ship
It seems as though what people are more interested in are packageable components. FWIW, to me it seems like JSR168 (Portlet API) can solve quite a lot of those issues quite nicely.
I've been implementing the proposed API (i.e. the WPS4.1 portlet API) in our own portal product, and I'm very pleased with it so far. It seems to allow for proper component packaging, and page composing using those components.
Howard, what's your take on JSR168?
/Rickard
-
Porlet API[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 01 2002 16:51 EDT
- in response to Rickard Oberg
I'm sorry ... I don't have an opnion; I haven't read it. Perhaps I should. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Adam Greene
- Posted on: August 31 2002 10:43 EDT
- in response to Jochen Krause
"extremly exited" -- to quote Jochen Krause. Yes we are extremely exited. JSF is just another MVC that uses taglibs, just another MVC that makes life easier than JSP, but it needed to go further. Take a look at Tapestry, it is a complete seperation of HTML and Java, with an easy to use component architecture. Tapestry is closer to being able to compete with M$FT, it simply lacks the components, which the Tapestry community is working to rectify. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Adam Greene
- Posted on: August 31 2002 10:44 EDT
- in response to Jochen Krause
"extremly exited" -- to quote Jochen Krause. Yes we are extremely exited. We are leaving JSF, being, and getting out of here!!
JSF is just another MVC that uses taglibs, just another MVC that makes life easier than JSP, but it needed to go further.
Take a look at Tapestry, it is a complete seperation of HTML and Java, with an easy to use component architecture. Tapestry is closer to being able to compete with M$FT, it simply lacks the components, which the Tapestry community is working to rectify. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Borislav Iordanov
- Posted on: August 31 2002 00:56 EDT
- in response to Robin Sharp
Robin,
In every library design effort, there is the usual tradeoff of generality of use vs. ease of use, abstraction vs out-of-the-box functionality. A standard specification such as Faces is probably better off concentrating on a strong foundation that accomodates as much as possible current practices and existing approaches, and that can be expanded upon, than providing ready-made widgets as a silver bullet that everybody should now use.
It's relatively easy to render a tree or a table in, say, HTML. The hard part is defining the server-side component model, the handling of the request cycle, component lifetime, state management, how all this could integrate with existing JSPs/Servlets, business logic etc... By providing a standard solution to those basic problems, Faces opens the way for plug&play of concrete, fully functional, interoperable UI components. Note also that, _functionally_, a web UI component is sometimes very much dependent on the target device. In other words, some browsers allow the implementation of such and such rich functionality, while others don't.
Having architected a similar to Faces framework (plus the trees, menus, tables etc.), which you can see at http://www.kobrix.com if you are curious, I speak from experience. The difficult decisions from day 1 were component lifecycle, state management, request/controller processing, what will a web programmer expect? Now that we are planning to integrate with Faces, we can focus a lot more on adding value through concrete, practical functionality and be confident about our product's acceptance and usefulness.
It seems like what you want to see is Swing for the web (like in your product). I don't think this is what the community needs in general. While I'm sure some people are very happy with swinglets (it really looks nice), I think web programming has some fundamental differences from desktop programming, both in terms of development practices and desired functionality (all coming from the markup/document element).
Cheers,
Boris -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Mark Allerton
- Posted on: August 31 2002 03:56 EDT
- in response to Borislav Iordanov
I'm totally with Boris on this one. The posters here who are disappointed that JSF does not provide a rich standard set of components seem to be missing the point - what JSF offers hope for is the opportunity for ISVs to supply re-usable web-tier components and have components from different ISVs work together. I work for an ISV (though of course my opinions are my own), and believe me, we need standards for this like yesterday. Personally, I like Struts and some of the other stuff discussed here a lot, but they do not meet this need - only an "official" standard can. In some ways, it doesn't even matter that much if the standard sucks in some ways, just so long as it is usable and it enables a web-tier component market. It's just a shame it's taking so long, because the void has meant that web frameworks are now like arseholes - everyone seems to have their own. I'll probably upset some people by saying this, but I think all of the "swing for the web" frameworks are really pretty lame, and I can understand why the JSF people wanted nothing to do with them. It's a dumb idea guys, give it up! -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Carlos Perez
- Posted on: August 31 2002 07:38 EDT
- in response to Mark Allerton
I completely agree with Mark.
The number of web frameworks for Java is completely ridiculous. The Java world needs a standard, so far it has been struts, unfortunately without the JCP blessing.
However, my main complaint is why has JSF taken so long to come out? Its an extreme disconnect when we compare the hype with reality.
Sure, it is nice that they've come up with standardization for Web UI components, but 2 years to come up with this is extremely absurd. It makes one question the abilities of the 50 so called experts.
A framework for Web UI components isn't even state of the art practice, its something that's been there for over 2 years. Just look at all those Swing for the web frameworks, lets see SwingLets, Wings, Echo, Webcream etc.
A framework for Web UI components is not enough. People are now talking about Portal frameworks. If I had to make the analogy from the GUI world. JSF defined a Standard for writing a Window, however their is no standard for writing a component. Think Netbeans or Eclipse, these provide standards for pluging in components into their framework. JSF does not address this. The next wave of frameworks are now addressing this Tiles, Tapestry, Portal frameworks etc. What's depressing is this need is not addressed and based on current commitee performance we might have to wait another 2 years! -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Reuben Cleetus
- Posted on: August 31 2002 10:14 EDT
- in response to Carlos Perez
I am extremely dissappointed with JSF! I cannot imagine that this is the crap that Sun has come out with, after two years of tantalizing tidbits scattered here and there about the rich UI and programmable components that JSF would bring. Get with it -- .NET Server Controls have changed UI design and programmable Web UIs for good, and JSF is simply no competitor!
What the Java world needs is not yet another reference specification, but a solid product that developers can put to use and more importantly, sell to their managers and clients.
Does Sun really think I'm going to be giddy simply displaying textboxes and option buttons on the web page?! Where are the Tree Views, the Tab Controls, the Spin Buttons...?! Where is the solidly programmable control?
In short, this is a major let-down, and Sun has proven yet again, that it is in no position to lead the challenge to .NET. JSF is quite useless the way it is, and I think its quite laughable to boot, that this is what Sun comes up with after two years of promises and the advent of .NET.
Regards,
Reuben Cleetus.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Dan Dubinsky
- Posted on: September 01 2002 08:33 EDT
- in response to Reuben Cleetus
Take a look at The JADE Open Framweork http://sourceforge.net/projects/salmon. It's what JSF should have been. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: August 31 2002 12:41 EDT
- in response to Borislav Iordanov
Basically, what you are saying is that it will be up to the vendors to provide useful implementations of the JSF components along with the tool support to use them well. There's no need to create a real reference implemenation, since that will just steal the vendor's thunder.
So we wait until the end of 2002 for a GA of JSF, then the vendors start issuing patches and updates to make use of it. In the meantime we "hope" that they get it right.
That just doesn't cut it with me; I want a real reference implementation that demonstrates the capabilities of the framework and proves that the design is powerful, flexible and valid.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Prakash Anthony
- Posted on: September 01 2002 11:39 EDT
- in response to Robin Sharp
Can't agree more with every word written here. There's absolutely nothing to get excited about JSF. JSF is a long way from what we were all expecting. Let's hope Sun does something to address these gaps before it's too late. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Mike Joslyn
- Posted on: September 03 2002 09:30 EDT
- in response to Robin Sharp
If you really want trees, split panes and pop up menus take a look at Flash Remoting http://betaprograms.macromedia.com, -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Stefan Mischook
- Posted on: September 03 2002 11:06 EDT
- in response to Mike Joslyn
Ok I have a few comments:
1. Web Objects is the buggiest piece of crap I have ever used. Corel makes more stable products. The IDE is equally as pathetic. Don’t buy into the hype … I did and paid the price of a month of wasted time. This is s a friendly warning.
2. Web Objects style of web-application creation has nothing major to add unless you are looking for a steep learning curve for little to no gain in terms of speed and ease of maintenance. The simple application of MVC with a few helper beans makes JSP work fine. I like thin frameworks – don’t believe in these huge monolithic projects like struts or Tapestry – sorry.
3. ASP.net web components really rock. Datagrids with paging built in – rich calendars – client and server side validations etc… Sorry coldtags is a nice start, but are a poor man’s version of the ASP.net web forms. If you don’t believe – just look.
4. Use what works: Copy ASP.net – I won’t mind.
5. I don’t use ASP.net because of vendor lock and general fear of M$ hidden evils. (Wait you need MDAC 2.72 to install that…)
6. People should stop trying to do everything and complicate the whole thing needlessly. Remember the 80/20 rule?
Stef
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Reuben Cleetus
- Posted on: September 03 2002 11:41 EDT
- in response to Stefan Mischook
I couldn't agree more! ASP.NET controls ROCK. Enough of the "we're going to create (yet another) impossibly entangled, insufficiently documented and hard to use 'Open Framework' because we fear IDE or Vendor lock-in." Enough. I'm a developer who wants to be productive, and I do not want to try to sell another hoplessly complicated "open framework" to my managers, when .NET sells something that integrates beautifully, works well, and provides amazingly rich web controls.
Geezz. Sometimes I wonder where all the folks who use JADE, Tapestry, etc. work. Surely not in any market I know, because here, if you can't finish a project on an aggressive deadline, or intergrate less-than-guru programmers into your project, you're not welcome. Unfortunately, as this article (http://www.internetweek.com/story/INW20020828S0003) points out, Java has failed miserably is getting out solutions that compete effectively with Micro$oft.
Yes, I would like to stay off Micro$oft's turf as much as possible, but Java is not making that easy. If I were a manager looking at doing Web Development, hell I may well choose .NET over <Name_Any_Open_Framework>! -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Mark Lesk
- Posted on: September 03 2002 14:08 EDT
- in response to Reuben Cleetus
I hate to say it but after looking through the ASP.net information on MSDN I completely agree. JSF is a half hearted attempt that is way way way behind the curve. ASP.net is definitely not something of beauty - the same old MS approach : push 10 pounds of it into a 5 pound bag ... but there are a lot of cool ideas.
What we need quite frankly is to perform a thoughrough analysis of asp.net and copy its strongest points and improve on its weak points and it has to be driven by an open source initiative not a closed process and a slooooowww process at that.
We can not pile more on top of struts - the underlying framework is already showing its stress points and it is only in 1.1 and not full release. Tapestry, Jade, etc I do not know enough about them to comment intelligently - yet. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Stefan Mischook
- Posted on: September 03 2002 18:30 EDT
- in response to Mark Lesk
I agree,
M$ has proven to be good at making easy to use products and their IDE's are generally considered to be the best out there. It is about time that Java copy M$!
So why not have a group put together a series of great taglibs that rip off ASP.net web controls. Simple to configure datagrids (with sorting and paging) connected to rowsets would save people time. A rich calendar component would be good too. Cold Tags has one but it is like an early beta release compared to the ASP.net version. They have some other nice things like databound select boxs and so on... I little Jakarta project could get these widgets out in short order and save people time.
We need JSP.net if you know what I mean ... Come on, M$ spent more money than God has thinking this stuff up, it is good.
Stef -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Borislav Iordanov
- Posted on: September 03 2002 19:52 EDT
- in response to Stefan Mischook
Guys,
Seeing the constant, shameless promotion of other frameworks/tools in a thread about a standard effort that threatens them ;), I feel the temptation to do my part: there's TICL at http://www.kobrix.com which I believe does a lot of things better than .NET (except, of course the "visual drag&drop tool" part). In fact, it is the best in terms of richness of functionality, ease of use, flexibility and integration with your current approaches ;)
You've got rich self-contained components, most with a client-side DHTML version, very flexible event model, browser differences handling, high-level styles/rendering, rule-based form validation with support for both client-side and server-side validation, forms-beans mapping with customizeable type conversions etc. etc. Soon to come things like JSTL expression language support, IDE plugins more renderers/skins/styles, including a .NET-like calendar date input, implemented simply as a custom renderer for the DateTime control, more components. Later to come, judging at least from the current version of Faces, an implementation of the JSF spec as part of TICL.
There was an announcement about the release a month ago:
https://www.theserverside.com/home/thread.jsp?thread_id=14757
BTW, I agree that .NET is great mostly because of Visual Studio. That's what speads productivity so much, not the framework and that's what, in the Java community, we need to work on.
Cheers,
Boris -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Pete Cassetta
- Posted on: September 04 2002 22:48 EDT
- in response to Borislav Iordanov
Borislav,
Yes, your framework is very good. The only thing that has kept it from being an option for me is the licensing. You require $250 per server (correct me if I am wrong), which makes it a no-go for low-end client sites (my focus). I even build some sites for nothing but the hosting revenue they will bring in...
I think the commercial orientation of your framework, while perfectly reasonable, sets it off from the open-source frameworks under discussion in this thread (Tapestry, JADE, Echo, and I don't remember which others), so you should point that out when you put in a plug for TICL. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Borislav Iordanov
- Posted on: September 05 2002 05:46 EDT
- in response to Pete Cassetta
Pete,
Thanks for the comment! The price of TICL by now is even more than that (it is largely justified by cutting down development costs), but free for non-commercial use.
In any case, we are working on more licensing options, for example for hosting companies that want to provide TICL in their offerings, or consulting companies that are adopting it for many small projects, such as seems to be your case. So if you find TICL useful, write to sales at kobrix dot com, or even better, to me at borislav at kobrix dot com (naturally, I'm personally interested in a wider TICL adoption ;) and we can discuss.
Cheers,
Boris -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Fred Cahill
- Posted on: September 03 2002 19:54 EDT
- in response to Stefan Mischook
Check out jade at http://www.sourceforge.net/projects/salmon, it has datatable components already available in JSP form and many others, they are all bindable to a datastore equivalent to a rowset. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Jon Tirsen
- Posted on: August 31 2002 03:09 EDT
- in response to Floyd Marinescu
I have to agree with the posters here. I've also been eagerly waiting for Java Server Faces and from what I've seen so far this is a great disappointment.
JSF had the chance to be the final word when it comes to web-components. Finally we could have a Swing for the web that was fully supported with tons of nice features and ready-built components, and fully supported, high-quality, well-documented. No, it didn't happen. Instead we got another set of tag-libraries no senior professional is going to use because everybody knows JSP stinks.
Sure, this is only a draft and you could have your saying and so on. But they've set the ambition-level for this one. "We're not going to promote it, we're not going to create good technology, we're not going to go heads-on with .NET. Because secretly we've sould all our stocks in Sun and bought Microsoft instead."
Well, maybe this is the final word anyway. Commercial software is on the fall and in this area open-source is going to rule. Be it Tapestry, Struts, WebWorks, wingS, what have you. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Dmitry Namiot
- Posted on: September 02 2002 09:58 EDT
- in response to Jon Tirsen
I think you should not be "disappointed" with JSF. JSF is nothing without IDE support. Actually it is a standard (or at this stage an attempt to suggest a standard) for IDE vendors. Do not forget that the core idea of ASP.NET components is Visual Studio support. So without IDE support for JSP you may continue to use existing taglibs (with menus, tree, .NET similar components etc.) like TICL or Coldtags
Dmitry Namiot
Coldbeans
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Vic Cekvenich
- Posted on: August 31 2002 07:28 EDT
- in response to Floyd Marinescu
They said people would write all these great EJB libraries?
This is the plan for the JSR, to duplicate EJB?
You want to be more upset?
a. A claime that they are the reference implementation of Java
Server Faces (and I mentioned it to the JSR and now they backed of a bit,
but I suspect that they have something to do with Sun on JSF)
http://www.qbizm.cz/newsletter.html
That is disapointing.
(IMHO Sun is a HW company and they have oversold their <OPINION>slow</>
HW. I think they will go the way of Digital, Data General, MIPS, etc. and
fade away. )
Let Sun go out of business, we will take the licks, and then compete.
This IMHO is good for Java, Java without SUN (we have IBM VM, Jikes, open
source Java, many Java alternatives). This would allow Java to compete on
SW. (and anything that was meant to sell more HW, such as EJB or the web
server + app server + EJB server concept goes out the door, Tomcat or Resin,
etc can do all 3 just fine. I found EJB limits the number of concurrent
users you can have per box severely compared to other DAO implementations).
(Why am I hard on Sun? I think lots of Silicon Valley start upd went out of bussines by spending to much on J2EE and SlowLaris, thus I have less clients)
c. I have urged my clients to stop using SUN VM and use the faster IBM VM.
(Sun has GC and other issues under load. There are lots of faster VMs, like
JRockit or TowerJ) My clients, some of them quite large are leaving Sun HW
and Sun Java to Linux and IBM VM. Other example is the Apple Java on OS X.
</RANT>
d. NET can be improved via a MVC framework, Maverick. (most of you know of
Maverick as a Struts competitor)
http://mavnet.sourceforge.net/
e. Still the best practice, better than .NET is to use Struts, with JSTL,
with Tiles and with DAO interfaces. I tried to document best practices for
web site development and implement those in code at basicPortal.sf.net.
(it uses for example declarative security and has verticals samples)
Vic Cekvenich
"Struts Mentor"
vic at baseBeans dot com
-
THE CRAPPIEST AND RIDICULOUS SPECIFICATION OF SUN[ Go to top ]
- Posted by: pierre loire
- Posted on: August 31 2002 13:22 EDT
- in response to Floyd Marinescu
2 years to come out this ridiculous specification,
I'm deeply disappointed, I believed JSF will compete with ASP.NET. But now, I'm sure ASP.NET will kill JSP and may be .NET will kill J2EE, SUN Microsystems has proved to be unable to compete with .NET .Even the well known company "The Mind Electric" (GLUE Webservices Platform) uses ASP.NET for its website although his product includes their own JSP/Servlet container.
What happened to Netscape could happen to J2EE. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Igor Zavialov
- Posted on: August 31 2002 14:19 EDT
- in response to pierre loire
Pierre Loire: "Even the well known company "The Mind Electric" (GLUE Webservices Platform) uses ASP.NET for its website although his product includes their own JSP/Servlet container."
Is that so? Unless they are forging the server signature, they are running Apache 1.3.26 on *nix.
-- Igor -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: pierre loire
- Posted on: August 31 2002 17:13 EDT
- in response to Igor Zavialov
Igor: Visit the download page of GLUE:
http://www.themindelectric.net/download/
You will recognize an ASP.NET page, if you are not sure , check the page source, it's written with VS.NET
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Reuben Cleetus
- Posted on: August 31 2002 23:02 EDT
- in response to pierre loire
HA HA! Pierre Loire's right!! The page (GLUE) is written in ASP.NET, using C#, no less!!
:) -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: eric larson
- Posted on: September 08 2002 19:39 EDT
- in response to Reuben Cleetus
Yup, ASP.NET generator. I imagine that's why the HTML code fails validation.
W3C HTML Validation Service Results
Warnings
* Warning: No Character Encoding detected! To assure correct validation, processing, and display, it is important that the character encoding is properly labeled. Further explanations.
Below are the results of attempting to parse this document with an SGML parser.
* Line 8, column 19:
<frameset border="0" frameSpacing="0" frameBorder="0" rows="*,47">
^
Error: there is no attribute "BORDER" for this element (in this HTML version)
* Line 8, column 36:
<frameset border="0" frameSpacing="0" frameBorder="0" rows="*,47">
^
Error: there is no attribute "FRAMESPACING" for this element (in this HTML version)
* Line 8, column 52:
<frameset border="0" frameSpacing="0" frameBorder="0" rows="*,47">
^
Error: there is no attribute "FRAMEBORDER" for this element (in this HTML version)
Sorry, this document does not validate as HTML 4.01 Frameset.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Igor Zavialov
- Posted on: August 31 2002 23:49 EDT
- in response to pierre loire
Download page is served from a different server. Possibly some kind of hosting arrangement, otherwise makes no sense to me.
-- Igor
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Chad Johnson
- Posted on: September 01 2002 13:12 EDT
- in response to Igor Zavialov
FYI:
The site www.themindelectric.net is running Microsoft-IIS/5.0 on Windows 2000.
http://uptime.netcraft.com/up/graph/?mode_u=off&mode_w=on&site=www.themindelectric.net&submit=Examine -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Clifford Cheng
- Posted on: August 31 2002 17:15 EDT
- in response to Floyd Marinescu
As with most web developers I've got really tired of the dumb html. I've been looking around for some non-html based alternatives in the last few months including
- Flash MX (Macromedia)
- XForms (W3C's next generation of web form)
- Apache Cocoon (XForms implementaion)
- XUL (e.g. Netscape 6 using the Mozilla engine)
- XUP (W3C event model to work with XUL, WML, etc)
If you take a look at Netscape 6, it has got everything we need. The book "Essential XUL Programming" from Wiley gives a good insight of this technology and how you could use it in web applications such as eCommerce. Though XUL is not a W3C standard but it's counterpart WML is not either. But WML has got most of the features we want and it's used on most Internet cell phones. Flash MX is also a popular plug-in and has got all the interactivity we need. I wouldn't throw away J2EE just because of JSF. After all it's just a skin. Why not take a look at other possibilities?
Clifford Cheng
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Chad Johnson
- Posted on: September 01 2002 13:26 EDT
- in response to Floyd Marinescu
There are many people bashing JSF here. Could someone actaully explain why they feel JSF doesn't cut the mustard instead of just saying that Product Blah Blah is 10x better? -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Robin Sharp
- Posted on: September 01 2002 14:12 EDT
- in response to Chad Johnson
"This specification defines an architecture and APIs which simplify the creation and maintenance of Java Server application GUIs" (JSR-127) != HTML Form Components (JSF1.0)
A one line macro fullfills this criteria, if you're into splitting hairs ... but "The truth the whole truth and nothing but the truth" or being "Economical with the Truth" are 2 well known phrases that sping to mind.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Chad Johnson
- Posted on: September 01 2002 14:51 EDT
- in response to Robin Sharp
JSF is more than just GUI Components. I think this sentance is a better summary:
"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"
In my opinion the real power of JSF lies within creating your own GUI components and wiring them to events handlers.
JSF 1.0 seems to be focused on nailing out the core framework for the problem at hand (see description above). Perhaps we'll see more prepackaged GUI components in future revisions of JSF but the lack there of does not a bad specification make. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Robin Sharp
- Posted on: September 01 2002 15:28 EDT
- in response to Chad Johnson
so we agree not complete & not bad -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Dan Dubinsky
- Posted on: September 01 2002 18:02 EDT
- in response to Chad Johnson
In my opinion the real power of JSF lies within creating >>your own GUI components and wiring them to events
>>handlers.
To be able to build the simple components into complex ones (for example multiple text edits repeating in different rows in a data grid), the simple ones have to be designed with that in mind. I think the JSF components are over simplifications just like the components in the AWT.
If you have to write your own components how do you get them to play nicely with GUI painting tools? After writing a framework like this myself I know that the tool needs intimate knowledge of the tags and components to really work well. Otherwise all you produce is property sheets that are so general that they are really little better then typing everything by hand.
That's was the big promise with JSF, that it would make you more productive by allowing better integration with tools. But there are only a hand full of very simple components. So now each vendor that implements JSF (the J2EE server folks I imagine) will include their own set of smart components along with their own tool set so they can give you enough to actually create a working application. That will serve to lock you into that vendor's J2EE server and tool set. Then in a year after everybody complains they will do JSF 2.0 with all the fancy components and you will have to flush your current apps and start over. Like going from AWT to Swing.
Take a look at the JADE Open Framework http://sourceforge.net/projects/salmon. It has a component model, an event model, automatic binding of the GUI to back end data sources, built in tool support, a ton of components like data grids, navbars and trees and has been battle tested in many real world applications (and we eat our own dog food). -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Chad Johnson
- Posted on: September 01 2002 19:07 EDT
- in response to Dan Dubinsky
Dan / Howard,
You both seem to be making similar points. Your feeling that JSF won't scale to handle more complex GUI components. What is an example of a component (feel to be abstract) that is that complex? -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 01 2002 21:10 EDT
- in response to Chad Johnson
Please check out this OnJava article I wrote last year:
http://www.onjava.com/pub/a/onjava/2001/11/21/tapestry.html
It describes the Tapestry Pallete component. It combines custom HTML with application specific stylesheet and images and tons of dynamically generated client-side JavaScript.
Here's a live demo:
http://tapestry.javanuke.org/tutorial/workbench
(Click on the Palette tab.)
You can drop a Palette component on any page with no special conditions or setup(*), use as many as you want on a single form or in multiple forms on the same page.
It is packaged as a JAR but still supplies default images, which you can override.
The two title bars ("Available" and "Selected") can be overriden to any arbitrary HTML ... even additional Tapestry components. (For example, you might want to put a Help component that generates a button raises some help in a popup window).
Anyway, although this is a year out of date, it represents my vision of what a component is: richly interactive, easily configured and capable of being dropped in on any page.
(*) Footnote: The single requirement is that the <body> tag for the page be implemented using the Tapestry Body component. This component renders the <body> tag, but also coordinates the generation of dynamic JavaScript by any components within the page.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Chad Johnson
- Posted on: September 01 2002 22:10 EDT
- in response to Howard Lewis Ship
Howard,
So a main beef of yours with JSF is that is doesn't adequately scale to meet the needs of components like the one you just mentioned? -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 01 2002 23:12 EDT
- in response to Chad Johnson
Also, what there just isn't elegant.
And there's lots of cruft in the JSPs, rather than clean HTML templates.
And you have to write too much code to get anything done.
For example, here's the total amount of code needed in the Palette demo to setup the Palette:
private IPropertySelectionModel colorModel;
private String[] colors = { "Red", "Orange", "Yellow", "Green", "Blue", "Indigo", "Violet" };
public IPropertySelectionModel getColorModel()
{
if (colorModel == null)
colorModel = new StringPropertySelectionModel(colors);
return colorModel;
}
private List _selectedColors;
public List getSelectedColors()
{
return _selectedColors;
}
public void setSelectedColors(List selectedColors)
{
_selectedColors = selectedColors;
}
This, plus the page specification, allows the Palette to read the current selections on render, and provide an updated List of selections on submit. It's a couple of accessor methods. Clean and simple.
To use this component on a page, you must specify it:
<component id="inputColor" type="contrib:Palette">
<binding name="model" expression="colorModel"/>
<binding name="selected" expression="selectedColors"/>
<binding name="sort" expression="sort"/>
<static-binding name="tableClass">palette</static-binding>
</component>
Again, short and sweet. Each of those bindings is matched up against a formal parameter (in the Palette component specification) that defines the type of value expected, required or optional and even a short description that's used by Spindle (the Eclipse plugin for Tapestry).
That is also about managing complexity, from the developer angle. It's should be very easy to do simple things.
Go back to the demo and click the Inspector icon (on the lower right). At runtime, Tapestry can show you how the entire application is configured, which is very useful for debugging. Tapestry is pretty unique in terms of this kind of introspective capability. This is part of "developer friendly".
Back to JSF ...
And its based on taglibs, which are pretty weak to begin with. See above example.
Exception reporting is also very important to me. Tapestry has multiple layers of exception handling and reporting. On the live demo, click the exception tab, then the indicated link. That's a Tapestry exception report (I've cleaned up the look since 2.0.4, the version running at javanuke). Anyway, tons of useful information there, again, supporting the developer (the information needed is likely right there, no need to fire up the debugger, re-run the app, etc.).
So I have a vague requirement that the framework should simplify things, make them fun ... but not get in the way.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Christian Sell
- Posted on: September 02 2002 03:31 EDT
- in response to Howard Lewis Ship
what I also dont see in JSF, nor in JADE or many other WebFWs, is component aggregation. This is where you can build a new component in terms of other pre-existing components. The only framework I know that addresses this properly is tapestry (I am not a tapestry missionary!).
But maybe Rickards pointer to the portlet API is useful here.
Christian -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Andrew Harris
- Posted on: September 02 2002 04:38 EDT
- in response to Christian Sell
As I haven't fully digested the spec, I don't wish to comment on the spec as a whole, however I do have two concerns.
I cannot see a true UI component mechanism, with independently installable and composable components. I see some component classes, but no true components. Perhaps this is still in development?
Do we have to have a new validation mechanism with every UI toolkit? The current validation classes are bound to the Faces UI and cannot be used without a UI or with another UI, as far as I can see. We had some new validation already with JDK 1.4, with JFormattedTextField; this was tightly coupled to Swing and apparently not usable elsewhre. I'm disappointed that there is no separation between the UI and non-UI aspects of validation. I would be looking for a non-UI package, say javax.beans.validation, which defined validation and type conversions:
o String to Object - parsing
o Object to String - formatting
where the parsing was tied to the validation: if the validation succeeded, then the parse should not fail.
This package could be exception-based, with ValidationException say; though there are differences of opinion as to whether exceptions are appropriate for validation.
Then this UI-independent validation could be reused with any UI, or without an interactive UI, for report generation say or XML data validation.
The Faces validation could be built on this reusable validation. I'd also like to see validation components: different validators based on the same class. For example, there might be an integer range which is used throughout an application, say [1, 10]. This could be created from an integer range class then given a name and made available as a validation component. In summary: provide declarative validation, and separate validation definition from binding to UI components, so that common validation can be shared.
It would help to have a more realistic example for Faces so we could see how the principles work in practice.
Andrew Harris -
The Problem with Tapestry...[ Go to top ]
- Posted by: Carlos Perez
- Posted on: September 02 2002 09:08 EDT
- in response to Howard Lewis Ship
The problem with Tapestry is that it was developed without considering political issues.
The biggest one of them is the support of JSP. It also doesn't use taglibs another strike against it. See, these standards need to use existing standards, regardless of how pointless that may be.
The JSP/Taglib spec is clearly breaking under its own weight. The JSF RI had to "hack" around it just to make their stuff work, notice that it uses a file called "jasper_hacked.jar".
Come to thing about it, hacking the jasper file, that's a pretty bad thing to do, considering you want standards to work on other standards. What exactly did they hack? Couldn't they have done it without resorting to these kind of extreme measures?
In summary, for Tapestry to get a wider audience, it'll need to address a lot more political issues that technical ones. JADE is more "compliant" with the standards, of course you have to get over than GPL license. Echo has the same problem as Tapestry, again it ignores the JSP and TagLib spec. WebWork is more "politically correct" framework, it supports taglibs however it opens the door for other template mechanisms like Velocity.
-
The Problem with Tapestry...[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 02 2002 09:52 EDT
- in response to Carlos Perez
Damned if you do, damned if you dont.
If I had made comprimised on Tapestry, such as implementing it as a JSP taglib, then I'd be politcally ok, but the framework would be about 10% as good.
By embracing servlets, but not JSPs, the framework is at "full strength" and continues to get better all the time(*) ... but continues to be sidelined a bit.
I do notice that Tapestry mindshare is increasing pretty rabidly though, and that's good.
(*) Example: With all the discussion of client-side validations, I decided to finally put some into the framework. Since I already had the validation framework and the JavaScript templating language, I was able to extend StringValidator to implement client-side validation (for minimum input length, and for required) in about 40 lines of Java code, plus a 35 line script template. Took about half an hour total. -
The Problem with Tapestry...[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 02 2002 11:04 EDT
- in response to Howard Lewis Ship
Funny. "Rabidly" may be accurate, but I mean "rapidly.". -
Tapestry with JSP[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 03 2002 19:20 EDT
- in response to Howard Lewis Ship
But what if you could embed Tapestry components into a JSP?
Despite a light-years wide gap between the two approaches, I recently (15 minutes ago) came up with a plan to allow this. Will that silence all critics? What we'll have, in effect, is the ability to use a JSP instead of a Tapestry HTML template. You'll be able to use whatever JSP taglibs you like ... plus Tapestry components with all of their power. -
Tapestry with JSP[ Go to top ]
- Posted by: Mark Lesk
- Posted on: September 03 2002 21:18 EDT
- in response to Howard Lewis Ship
Would go a long way to increasing adoption imho. -
Tapestry with JSP[ Go to top ]
- Posted by: Carlos Perez
- Posted on: September 03 2002 22:33 EDT
- in response to Howard Lewis Ship
Howard,
You've got a good framework, however if you want it to gain more mind share then creating the hooks to other paradigms is the way to go.
Tapestry would be great if I could treat it just like another taglib.
It would be even better if a Tapestry component would work as a JSF page.
People just can't handle the paradigm shift of Tapestry, providing a easy migration path from JSPs would be a good extension. -
Tapestry with JSP[ Go to top ]
- Posted by: Jonathan Asbell
- Posted on: September 09 2002 00:18 EDT
- in response to Carlos Perez
I was intrigued by Howards comments and wanted to give Tapestry a whirl. I have now been playing with it for a day trying to get it to work with the latest Tomcat and I am getting frustrated. I cant seem to find a user list, and the developer list link seems to be broken. The tutorial war file does not deploy correctly in the latest Tomcat, and I dare not try weblogic yet. The instructions on install suck, and the ant build fails with jboss3. So much for that. -
Tapestry with JSP[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 09 2002 07:21 EDT
- in response to Jonathan Asbell
There is a link to the Tapestry developer list from the Tapestry home page: http://tapestry.sf.net. The lists are run by SourceForge using GNU Mailman, they tend to be quite stable.
The install diredctions are very explicitly for JBoss 3.0.0, you must have tried to install under 3.0.1 or 3.0.2.
The tutorial.war deploys correctly after you've put Tapestry and its related JARs into the Tomcat classpath.
The instructions on install does not suck; I have never gotten a bug about installing that wasn't somebody using the wrong version of JBoss even though the instructions say in bold, italic font "use JBoss 3.0.0 only".
WebLogic has its own set of problems; you have to rename the Tapestry JARs to remove any periods in the name (except for the .jar part). -
Tapestry install problems[ Go to top ]
- Posted by: Jonathan Asbell
- Posted on: September 09 2002 12:48 EDT
- in response to Howard Lewis Ship
you are wrong Howard. Tapestry does not install under jboss3.0, which by the way does not work with JDK 1.3 and higher. -
Tapestry install problems[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 09 2002 13:02 EDT
- in response to Jonathan Asbell
I do my work on Windows; I currently don't have a Linux machine. Could that be the problem? I haven't heard of any problems on the Tapestry developer list, users there are on many operating systems and many servlet containers.
I do a considerable amount of testing, on windows, using JBoss 3.0.0.
You'll find many folks, besides me, waiting to help if you post on the Tapestry developer list. -
Tapestry -- Getting Right JBoss Version[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 09 2002 13:19 EDT
- in response to Jonathan Asbell
JBoss has changed the links on their site.
The link labeled "JBoss 3.0.0" is now actually to the JBoss/Tomcat bundle, which isn't the version of the JBoss distro that Tapestry can automatically configure.
You need jboss-3.0.0.zip, which is JBoss bundled with Jetty. -
Tapestry with JSP[ Go to top ]
- Posted by: Clifford Cheng
- Posted on: September 03 2002 23:39 EDT
- in response to Howard Lewis Ship
"Despite a light-years wide gap between the two approaches, I recently (15 minutes ago) came up with a plan to allow this."
See we do have great people and great technology in the Java community. We have great stuffs like Tapestry, JADE, Struts, ......, etc. All we need is somebody to put them together or provide the interoperability between them. -
No capable leaders[ Go to top ]
- Posted by: Ignat Skoryh
- Posted on: September 04 2002 12:52 EDT
- in response to Clifford Cheng
Yeah. This is the problem with the Java community. That from the one side java developers become selfish and try to push in each own direction, suggesting different but immature solutions to the same problems. And from the other hand Sun just unable to unite different sides to cooperate and work for our common benefit.
Sun was slow with organization and now we have a lot of frameworks that compete with JSF. This will cause in turn a lot of headach and lost time for all of us to decide which framework to use or what problems each framework is about to solve. And we could spend this time for improvments in Java.
Ignat. -
Tapestry with JSP[ Go to top ]
- Posted by: Pete Cassetta
- Posted on: September 04 2002 22:55 EDT
- in response to Howard Lewis Ship
Howard,
Did you really pull this off? Amazing.
Like it or not, JSP is mainstream, and the ability for Tapestry to integrate with JSPs would be a real boon. Tapestry seems to be gaining momentum among developers, and I think JSP integration would make it much more palatable for folks up to their ears in JSPs. Especially if adding Tapestry components to JSPs can offers some real benefit with a minimal learning curve. -
Tapestry with JSP[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 05 2002 09:13 EDT
- in response to Pete Cassetta
I believe I can pull it off. First is to finish of release 2.2. Release 2.3 will be the JSP interoperation.
You'll still have all the Tapestry paraphenlia (engine, request cycle, pages), but when it comes to rendering it will use a RequestDispatcher.include(). The Tapestry JSP tags will hook back into Tapestry code to render components.
Of course, the JSP can have JSF, Struts, JSTL, scriptlets or custom tags on it.
The models are very, very different and its going to take some rearchitecting on the Tapestry side to support it.
Many cool features of Tapestry will not work, such as (of course) invisible instrumentation (JSP instrumentation is always visible, I call it "cruft"), a few validations (there's no way to reconcile the ids in the template to the ids in the page specification), and the ability to use the direct service for form submissions.
Pages will require that Tapestry initiate the render (it has to stuff some attributes into the HttpServletRequest and do bookkeeping before and after the JSP renders).
I'll probably provide an implemenation of Struts ActionForward that loops through Tapestry to render pages, as well as utility code.
However, all the important features of Tapestry will be in place. You'll be able to drop complex components such as the Palette, complete with sophisticated client-side scripting, right into the JSP.
I'm hoping that this functionality will hook developers into abandoning JSPs entirely, in favor of the simpler and more powerful HTML templates used by Tapestry. It's a compromise (and I'm not a huge fan of those), but it's necessary. -
Tapestry with JSP[ Go to top ]
- Posted by: Carlos Perez
- Posted on: September 05 2002 10:35 EDT
- in response to Howard Lewis Ship
Howard,
I think its the right steps, that is move towards standardization. Maybe you might make technical compromises to support standards, however doesn't mean you have to sacrifice the non-standard features. Tapestry is good, but will it go the way of other really cool technologies like Amiga, NextStep, BeOS. Ahead of their time, but unfortunately didn't make it to critical mass.
If you want "Invisible Instrumentation", why can't you just define a simple jsp tag for tapestry (i.e. <jwc:tag id="here"/>), then tie everything together inside the tag implementation?
"Pages will require that Tapestry initiate the render", well you can do this the JADE way, where you everthing works withing their own "page" tag. Or you could try the Tiles way, that is provide your own action controller "derived" from the struts controller.
Best of luck!
-
Tapestry with JSP[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 05 2002 10:52 EDT
- in response to Carlos Perez
Examples of "invisible instrumentation":
<span jwcid="insertDate">12/24/1966</span>
<form jwcid="form">
<input type=textfield jwcid="inputName" class="required"/>
Etc.
Because Tapestry has its own parser for HTML templates, it doesn't have to use the JSP taglib syntax and, in fact, simply looks for the "jwcid" attribute.
JSP tags don't have the equivalent of Tapestry's informal parameters; they require every legal parameter to be statically defined. -
Tapestry with JSP[ Go to top ]
- Posted by: Malcolm Edgar
- Posted on: September 05 2002 20:57 EDT
- in response to Carlos Perez
The problem I see with JavaServer Faces is that it is built on JSP and Tags. This is not a good foundation for a component framework. Why, because JSPs and Tags are basically serial output devices.
Tags have very little contextual information about where they are in a page and what relationships they have with other Tags. Why is this important? Well how does a Tag attach an event Javascript handler to itself in the HTML <body onload=""> when that has already been written. And this is only the start.
The complexity of trying build on web component framework on this JSP/Tags is awful. User Interface frameworks is not Sun's specialty, if you want to see what can be done in an elegant fashion have a look at Tapestry.
-
Tapestry with JSP[ Go to top ]
- Posted by: Borislav Iordanov
- Posted on: September 05 2002 21:45 EDT
- in response to Malcolm Edgar
Malcolm,
1) JSF in not build on JSP and tags, that point has been emphasized a lot. JSP and tags are one means to use JSF components.
2) Tags have quite enough contextual information about where they are in a page. They can act as serial output devices, but they can also buffer content and work on it dynamically in a cooperative fashion. The tags architecture itself is very flexible and powerful in that respect!
3) I'm not familiar with Tapestry and its elegance, but if it's going to buffer the whole response on every request so that I can attach a <body onload=""> event at a later time, I would be extremely sceptical about its performance on heavy load.
Especially that problem of attaching DOM event handlers at times different than the actual markup rendering can be solved without having to store the whole response in memory (in whatever representation). As it's done in TICL, where we have been very careful in minimizing server ressources and client memory footprint (when serializing components in the response for request processing after what JSF calls a "postback").
Cheers,
Boris -
No Problem with Tapestry...[ Go to top ]
- Posted by: bill salamanca
- Posted on: September 09 2002 01:48 EDT
- in response to Howard Lewis Ship
Hay Howard, don't let it get you down, we need people of vision and passion like you but it would be nice if you all got together and created a slightly smaller number (but more awesome) of (MS) killer frameworks.
A while back my colleagues made a judgement on my development skills and make me a manager to minimise the harm I could do. One of the interesting things they left me with was identifying tools that would make them more productive. We are a pretty pragmatic bunch, interested in the short term, quick results, nice if it's build on a standard but we can't always wait, you know the sort of thing, we are all under the gun theses days.
I like your stuff, it has the right feel but what would be really helpful would be a bit of a catalogue of components (trees, collapsible sections, menus, grids, etc), you say yours is one of the only true component frameworks, I would have thought then examples would be fairly transportable. Some other frameworks (echo / echopoint) have such things and it makes it easy to evaluate and try.
If we get hooked then we will be happy to contribute our stuff back. Keep it up and don't compromise the vision for the sake of jsp standard.
-
No Problem with Tapestry...[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 09 2002 07:28 EDT
- in response to bill salamanca
Getting together in the virtual, open-source world is a little problematic. We mostly post messages at each other.
I've gotten together with Anthony Eden, in that I put together a Tapestry example for his Wafer web project.
What's happened in the Tapestry community is that lots of people have developed lots of their own widgets but haven't contributed them back. It is true that making a truly reusable components takes a slight knack (for instance, remebered to make any images used configurable, so that you can adjust the L&F for different applications).
The community, as well as myself, have seen this and are promising to address this issue. For example, a DatePicker component was just contributed and will be in beta-2.
I've been working on taking the existing ValidField components and adding client-side validation to them. This is painful only because I'm not very good at cross-browser JavaScript (it's an arcane science).
Finally, and I know I'm opening myself up for flames because of my JSF hype vs. spec post .... but finally, the beauty of Tapestry is how its structured on the inside, not the flashy components you can create with it. It's the fact that the application is succinct and readable. -
No Problem with Tapestry...[ Go to top ]
- Posted by: Stu Charlton
- Posted on: September 09 2002 10:35 EDT
- in response to Howard Lewis Ship
well, I've managed to ignore most of the posts on Tapestry in this tread because IMHO it's offtopic. BUT, I will say that your persistence has made me go out and download the sucker. <grin>
-
Tapestry thread[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 09 2002 13:05 EDT
- in response to Stu Charlton
I am sorry that the Tapestry thread has taken over here. Floyd M. didn't want to post my Tapestry 2.2 beta announcement here, which would have shifted discussion onto it.
(I kind of disagree, I wouldn't expect TSS to post all my alphas, betas, etc., but first beta and GA seem like fair game ... but Floyd wants the GA release only).
The JSF issues has definately energized the Tapestry community. Nothing like the threat of competition. -
No Problem with Tapestry...[ Go to top ]
- Posted by: Stefan Mischook
- Posted on: September 09 2002 16:25 EDT
- in response to Howard Lewis Ship
Howard,
You can borrow :) the ASP.net cross-browser JavaScript - just donwload ASP.net and you will find all the scripts in a few JS files.
Stefan -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Dan Dubinsky
- Posted on: September 01 2002 22:21 EDT
- in response to Chad Johnson
For example, I think you would have a lot of trouble implementing tabular components (grids, lists) that leverage the standard components in the framework. That sort of functionality needs to be built in the foundation because the base components need to know how to work with tabular data instead of single values.
See an example at:
http://www.salmonllc.com/jadeExamples/Jsp/example8/ContactList.jsp
See a bunch of examples of other kinds of components at:
http://www.salmonllc.com/jadeExamples/Jsp/HomePage.jsp
See a video on how this sort of thing can be used in an off the shelf GUI painting tool:
http://www.salmonllc.com/website/Jsp/vanity/JadeVideo.jsp?nav=5&NavBarId=JadeVideo -
Problems with JSF[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 01 2002 17:02 EDT
- in response to Chad Johnson
I think many of the comments here, and on the other JSF thread https://theserverside.com/home/thread.jsp?thread_id=15227 are reasonable comparison.
People are reeling because JSF has promised the world and delivered dog food.
We were lead to expect a well thought out, well integrated framework with powerful, reusable components and a sophisticated client-side aspect.
We got some basic form controls with a smidgen of server-side validation thrown in, and layers and layers of complexity beyond Struts and some glaringly obvious design flaws (such as the ApplicationHandler) that we just have to hope will be addressed.
In addition, the demo was especially non-compelling. It was sloppy, finicky to run (inside JBoss 3.0.0) and didn't demonstrate to *me* that JSF makes things easier for anybody. In fact, I would choose Struts over JSF anyday of the week ... and I *hate* Struts.
The argument that better and more complex components will follow and be provided by vendors falls flat. As someone who has created this kind of framework ... the proof is in the pudding. You can hit some amazing brick walls when you try do do something complex. It's one thing for an early beta of Tapestry to change the API when I found out I couldn't do X ... it's another thing to release a public API, freeze it as "1.0 GA", and then loose it on the vendors. When they can't accomplish things because of gaps in the framework, it means kludges and a wait for "1.1" ...
Give me a kick-ass demo. Prove it works. Do things I can't do with my current framework. Do it better and with less code. And if Sun doesn't have the technical expertise to pull it off, adopt an existing product and run with it.
People are especially dissapointed (well, except for me, I'm thrilled because of my personal agenda) because this spec has been *two years* in the making.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Smythe
- Posted on: September 02 2002 04:53 EDT
- in response to Floyd Marinescu
PPl,
Very interesting thread. But I was wondering (as Im sure a few other people are) how does JSF compare to .NET serverside controls (NOT Tapestry!)?
Please Compare and contrast , is one more "complete" than the other, what functionality/components are present in one that aren't present in the other, or do they solve very different problems, etc...
Please try to be as unbiased as possible (im sure that is rather difficult on a J2EE forum but please give it a go... no bloodbaths please)... :¬)
Cheers
Smythe -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Carlos Perez
- Posted on: September 02 2002 08:34 EDT
- in response to Smythe
Smythe,
The main thread here is that a lot of people had high expectations about the JSF considering all the incredibly powerful Java frameworks out there.
However, here are my thougts. .NET server side controls are similar in functionality to the JADE framework. However, I think server side controls is less of a framework but more rather a bunch of controls. So making the comparison may be more like comparing apples and oranges. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Reuben Cleetus
- Posted on: September 02 2002 09:48 EDT
- in response to Smythe
Here's the problem with JSF... and Tapestry, and any other Framework attempting to create a true GUI framework for JSP development: They HAVE to compete with .NET!! As anyone who has had the chance to check out .NET (as I have on a major project), Server-Side controls are completely integrated into the IDE, allowing one to have the same access to method stubs as one would have using controls on a regular windows Application (Windows Forms, as they are now called). You simply double-click on the control, and voila, you're in the method stub for that control. Most properties are available on the property sheet, as in Visual Basic.
That is the kind of integration that is REQUIRED of any such framework, before Java can capably compete with .NET on a vast majority of Web Projects.
With Tapestry, you're constantly shuttling between Dreamweaver and your Java IDE to get things done -- not good enough! JSF had the chance to change all that.. and they produced another piece of chaos! For Sun to say that they're only producing a 'framework', which other vendors will extend into a full-fledged workable solution, is a cop-out. JSF needed to fully and aggressively compete and win against .NET.. Instead, it produced a lemon.
What annoys me is that it's not like the folks at JSF didn't have the .NET method to look and learn from -- after all, they knew (or should have known), that they would be competing head on with .NET for a great majority of web projects. The M$ guys responded well to JSP with ASP.NET, but the guys at Sun seem to be completely clueless about far behind the curve they have put themselves with this lame solution. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Dmitry Namiot
- Posted on: September 02 2002 10:17 EDT
- in response to Reuben Cleetus
That is the kind of integration that is REQUIRED of any >such framework, before Java can capably compete with .NET >on a vast majority of Web Projects.
Exactly! That is what I wrote too just 5 min ago :)
Existing Java frameworks can not compete with .NET
without an appropriate IDE. Otherwise you will write
by hand too many files for JSF (the same what we are doing
right now for EJB - do not tell me again about XDoclet :)
Dmitry Namiot
Coldbeans
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Bill Willis
- Posted on: September 02 2002 21:04 EDT
- in response to Reuben Cleetus
I tend to look at things from the other direction. Show me a good framework based on open standards that I can be productive with. Then show me nice IDE integration. This is why I like the Java community. We have a number of diverse, open, well thought-out frameworks that I can be very productive with. I think this diversity is great! Some of them, like Struts, are showing rapid growth in IDE integration. Others will follow, including JSF when it gets its act together.
Back in my Microsoft days, I thought VS was okay, but I often ran into brick walls with the underlying technology. VB was the worst offender here (I still have nightmares). It sounds like things have improved with .Net, but you are still stuck with a proprietary framework from a company that seems to concentrate more on its IDEs than its underlying technology. This could be viewed as good for the large body of inexperienced programmers out there, but I think it is a bad idea (especially for those who have to maintain the code MS encourages them to produce).
Others may disagree, but that is my own opinion born from quite a bit of experience on both sides. By the way, I still think the best language/IDE combo I have worked with to date is Object Pascal/Delphi. It put Microsoft to shame - and still does. Those were the days.
And one more thing. Let's not be so quick to judge JSF yet. We still have a ways to go before it becomes a final 1.0 release. The parts are still out on the table. You can criticize the time it is taking to put JSF out, but you should hold your judgement on its quality until the final version arrives. Constructive criticism is best at this point - hopefully the expert group will listen. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Borislav Iordanov
- Posted on: September 02 2002 22:55 EDT
- in response to Bill Willis
Finally a sensible comment ;)
Boris -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Dan Dubinsky
- Posted on: September 03 2002 08:28 EDT
- in response to Bill Willis
I think it is important to have a balance. You really need both good tool support and a strong technical foundation. Sun and the Java community don't have a good track record with any UI spec in either area. So far we've got Applets, AWT, Swing, and JSPs with in-line code. All of them are based on good ideas and good design patterns. But the spec is always too something: too simple, too complex, too flakey, too hard to use, too hard to maintain apps, too bandwidth hungry. Poor tools for all of them are pretty much universal.
I think they are going down the same path again, only this time the Microsoft freight train is coming around the bend and we Java programmers are sitting on the tracks. They don't have another two years to work on this and get it right. They still haven’t gotten the other ones to work right in how many years.
BTW: Silverstream had some great ideas in their tool (basically Powerbuilder for the web, another great tool in it's time). They were way ahead in the web space in terms of concept. We used it when it first came out something like three/four years ago, but the implementation back then was really really buggy and you had to run it on their server which blew up every couple of hours. Also they believed the hype and focused on applets and we know how that worked out. They may have fixed the bugs since then, but we couldn't wait and wound up doing our own framework, which eventually turned into JADE. Basically the same idea as Silverstream only open and it works.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Clifford Cheng
- Posted on: September 03 2002 17:17 EDT
- in response to Bill Willis
"We have a number of diverse, open, well thought-out frameworks that I can be very productive with. I think this diversity is great! Some of them, like Struts, are showing rapid growth in IDE integration. Others will follow, including JSF when it gets its act together."
Agree. Even if JSF didn't deliver, so what? When has J2EE become so fragile? It's not the end of the world. Be it ASP.NET or JSF, they are all html-based as far as I understand. I don't think html was intended for same functionality as desktop clients. Even with DHTML and Java Script it's still not a good solution. I believe the industry will eventually come up with better technology. -
SOMEONE ASKED ABOUT HOW JSF COMPARES TO .NET ???[ Go to top ]
- Posted by: Jonathan Asbell
- Posted on: September 02 2002 11:11 EDT
- in response to Floyd Marinescu
I dont see any difference. Here is a comment I wrote on another JSF thread:
**** This architecture is almost exactly the same as .NET ****
I am a java programmer, but my company sent me to a 3 day .NET training. Their "ASP .NET" architecture also makes a component representation of web form elements and links, and you can attach events to each element individually or instead as one unit together. Dot NET also attaches command objects to these components. The Dot NET MVC architecture is also based on a "post-back" concept so much, that a code line you will always use is "isPostBack()". The data source abstraction layer and its component architecture are the same as .NET, and the validation model and architecture are the same. There is more, but you understand where I am going. These two architecture are suspiciously similar in architecture and behavior. Is there a connection? Its a hell of a coincidence. If you are someone who knows both technologies, please comment on this. ~CoNsPiRaCy~ -
SilverStream had Web Components with IDE Integration YEARS ago[ Go to top ]
- Posted by: Michael McCutcheon
- Posted on: September 03 2002 00:46 EDT
- in response to Floyd Marinescu
I keep hearing about how all of the Java frameworks out there really separare the .jsp from the implementation of forms stuff in the Java classes. Believe it or not, but SilverStream has had an IDE that was an HTML layout tool, then click on the button, and you were taken to the event handler of the button in the Java class. Add a textfield and a corresponding TextField object was added to your class. An extremely tight integration between the HTML layout and the Java code. Change the name of the textfield, and the textfield throughout the class was changes, etc. Where I work (on web projects for the Navy), we are migrating from this to .jsp. WOW, what silverstream had YEARS ago was much better than any of the .jsp stuff. Too bad it was proprietary. If SilverStream would only open up all of their old AG code, then Java would have a competititor to .NET for this kind of stuff.
-
And dont forget Apple WebObjects[ Go to top ]
- Posted by: Christian Sell
- Posted on: September 03 2002 03:49 EDT
- in response to Michael McCutcheon
dont forget Apple WebObjects. It was there when many of us werent even dreaming of web application servers, and it already had all the stuff we are talking about today. It has a graphical IDE (somewhat deficient when it comes to complex HTML) to design your page, and custom controls that are wired to event handler code. Nothing new here. In fact, some parts of the JSF tutorial/spec look suspiciously similar to the WebObject documentation.
WebObjects, which once had a 5-digit price, is available today at a few hundred bucks. And as a small additional bonus, it even contains a persistency framework which I would prefer over EJB CMP any time.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: September 04 2002 19:37 EDT
- in response to Floyd Marinescu
All,
Frankly, I don't understand such a hot reaction to Subj.
I've read the PD through and I think it's good as far as standard can go. It has a potential for creating component libraries by 3rd parties, and the class structure is well designed so it should be easy to use. Sure it's not .net, but AFAIK nobody promised it would be. This is an API and it's up to you to provide good implementations and loved UI drag'n'drop tools (well, it's up to J2EE vendors :) So I think JSF should be in a good shape when released.
As for me, we developed something very alike (component web UI framework with trees-tabs-tables-etc), so the only thing that seems to be shameful in JSF PD is that I didn't manage to get a public version of it to beta stage by now. So I've lost an opportunity to advertise it here :-)) -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Pete Cassetta
- Posted on: September 04 2002 22:50 EDT
- in response to Slava Imeshev
Slava,
Since we're throwing around so much hot air on frameworks, it is perfectly reasonable for you to mention yours.
But please include a Web address where we can take a look. It sounds interesting. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Slava Imeshev
- Posted on: September 06 2002 19:10 EDT
- in response to Pete Cassetta
The framework is in pre-beta. Drop me a line to imeshev at yahoo dot com. I'll include you into release announcement list. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Borislav Iordanov
- Posted on: September 05 2002 05:52 EDT
- in response to Slava Imeshev
Slava,
I agree with every word in your post ;), and JSF is in pretty good shape already. There is a lot left unexplained in the spec, but the foundation is quite strong. I can't understand why people need fancy widgets as proof of concept in such a specification.
Boris -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Dan Holmsand
- Posted on: September 05 2002 08:39 EDT
- in response to Borislav Iordanov
It may also be worth noting that the EA is NOT supposed to be feature complete. The release notes says that "Some UI Components (Graphic, Panel, DataGrid, DataHierarchy), A Standard RenderKit, Object Management and Event Model" are still to come.
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: no name
- Posted on: September 05 2002 12:18 EDT
- in response to Floyd Marinescu
Guys,
Aren't you bored already of jsp/asp/html like interfaces? Don't you think it's time to move on to the next level? The user needs a much better experience than what's currently offered by page-oriented solutions.
Then, why bother writing so much code just for the presentation layer when it's the business you should concentrate on? Why don't use XML(XUL) based interface definitions. You already have the data that has to be presented and you probably have it in XML format.
And why you, as Java developers, have to be so concerned on the lack of visual components. There is an army of designers out there coming up everyday with one GUI component cooler than another. Take Flash MX as an example.
So, what about a Flash / XUL user interface ? Maybe something like Zulu.
Ovi Comes
-
Wings (to fly with)[ Go to top ]
- Posted by: vinay soni
- Posted on: September 05 2002 15:04 EDT
- in response to no name
I think people have forgotten WINGS. A Framework like Swinglets. It has Trees, Tables with regular Swing Models.
It also has Split Panes and Dialogs.
The code is almost the same as how u code in Swing. Don't have to learn something new.
I just love this Framework (after Struts, JSP and Swinglets)
Howard Ship, how do you compare your framework with Wings.
Find them at: wings.mercatis.de
Don't forget to look at their kick ass demo.
Vinay -
some reality checks[ Go to top ]
- Posted by: Stu Charlton
- Posted on: September 05 2002 16:30 EDT
- in response to Floyd Marinescu
JSF is a long-awaited attempt to make web components. I'll post my critique in the next message.
For now, I'd like to address what are, in my humble opinion, some shockingly misguided claims that have appeared in this forum.
First, WebObjects:
Qualm: Web Objects is the buggiest piece of crap I have ever used.
Retort: Did you call Apple support and file bug reports?
In my experience, WebObjects is pretty solid. Idosyncratic, but solid. It's also a primary influence for both ASP.NET and JSF, and is still very competitive with any web framework out there.
Qualm: "Web Objects style of web-application creation has nothing major to add unless you are looking for a steep learning curve for little to no gain in terms of speed and ease of maintenance. "
Retort: Please back this statement up with some facts, lest I just assume you were one of those people that dropped out of highschool math because "it's too hard and gains me nothing".
Here's a good example of WebObjects' productivity : Apple re-implemented the J2EE 1.2 PetStore in about 1,600 lines of code with WebObjects. It's in the 5.1 examples directory. *1,600 lines*. And no generated SQL code. That's significantly less that both .NET (around 3,100) and J2EE (11,000). I think you had a bad learning experience, something common with any rich framework. It's rich for a reason, though.
WebObject's major problem is that the documentation needs updating from prior versions. All the prior version documentation is applicable to 5.1, so it's livable, but not ideal.
Onto the .NET comparisons,
Qualm: "No tables. No trees. No menus. No swapable look and feels to PDF/XML/JFC. No nice chunky demos to rub the .NET'ers faces in. Basically no beef. If anybody was hoping for Sun to provide a competitor to the .NET Web Components they're going to be let down. "
Retort: This is like complaining to Ferrari that they don't make school buses. Your expectations were WAY out of line of ANYTHING that's come out of the JSF spec request.
I'd also like to know where in ASP.NET I can find these magical tree & menu components, and swapable look & feels. They're not there. They're just forms too.
Qualm: "Get with it -- .NET Server Controls have changed UI design and programmable Web UIs for good, and JSF is simply no competitor!"
Retort: How is a .NET server control *any* different from a JSP tag library? As you say in a later message, IDE support. That's the whole purpose behind JSF, and I find it perplexing that reading the spec doesn't show you how similar JSF is to System.Web.UI package.
Here's a general claim: JSF doesn't have to be *exactly like ASP.NET* to compete with it. ASP.NET has made some tradeoffs with their design: a good example is huge blobs of serialized data in ViewState for any moderately complex web form. The web world doesn't have to evolve around VB style controls & events, that's just one particular paradigm, and not the most effective one at that (see WebObjects for a more flexible one).
Stu -
some reality checks[ Go to top ]
- Posted by: Stefan Mischook
- Posted on: September 05 2002 20:09 EDT
- in response to Stu Charlton
.NET server control
They don't need supporting XML files to use them.
WebObjects:
I only played with WO's 5.1 for a little while. I did create some small apps with it and yes there was some nice stuff. Along with my own complaints I was on the Web Objects list and there was many a bug complaint, some that have been around for a long time and never fixed by Apple.
I am not claiming to be an expert in WO's, but I can safely say from my experience that it is buggy. I have used a lot of software over the years and when you compare WO's and what is the norm buggy comes to mind.
One thing that leaps to mind is the stupidness of needing 2 different JDBC drivers; one for EOF and another for Project Builder ... How about all the class path issues. With Resin for example, to get it going takes all of 1 minute. It gives me the shakes when I think of the time it took me to get WO's up. I have to say though that Apples support was pretty good.
Project builder/ WO builder (Windows version) reminds me of windows 3.0 applications.
It has been a while since I looked at it. I think though the biggest time saver is EOF. But on the other hand it can get pretty slow ...
It is clear that ASP.net took much from WO's, so what? The big difference is that ASP.net is free, it is easy to learn and the IDE is second to none.
The code counting stuff does not mean much, you can do the pet store with much less code is a JSP / bean combination with container load balancing ect... by just leaving out the EJB stuff.
When working with WO's you get excited because is seems to be exactly what the doctor ordered, but then you find yourself worried about all the quirks and bugs and work-arounds you have to deal with. Yeah, maybe if I spent a few months on it I could get productive but I spent a couple of days on JSP and things came along nicely.
I know WO people have a lot of passion about the product and seem to be inclined to resorting to insults (ex:I just assume you were one of those people that dropped out of highschool math because "it's too hard and gains me nothing". )
I look at these things as tools, like a hammer - I don't get emotional about it because frankly I don't really care.
Stef -
some reality checks (.NET)[ Go to top ]
- Posted by: Pete Cassetta
- Posted on: September 06 2002 00:47 EDT
- in response to Stefan Mischook
Stefan,
You say: "The big difference is that ASP.net is free, it is easy to learn and the IDE is second to none."
What do you mean by free? The last time I checked, Microsoft wanted a significant chunk of change for Visual Studio.NET. Also, you have to host .NET sites on a Microsoft platform, and they don't give away any of their server OSes for free.
Aside from the costs, have you ever hosted sites on Microsoft platforms? I have, and it wasn't fun. Reliability, security, and stability were not in a league with a basic Linux/Apache setup.
Another .NET drawback (for me) that nobody seems to mention is that Microsoft has a lousy track record in cross-browser functionality. I haven't played with .NET, but I'm sure those pretty Web GUIs that you can crank out so quickly with their IDE are going to have issues on Netscape/Mozilla and Opera, and I wouldn't be surprised if they have issues on anything but the latest IE versions too.
.NET may have some good ideas in terms of GUI and IDE, but the negatives (hosting on MS and lousy cross-browsr compatibility) are a show-stopper for me. -
some reality checks (.NET)[ Go to top ]
- Posted by: Stefan Mischook
- Posted on: September 06 2002 02:22 EDT
- in response to Pete Cassetta
Hi,
Your points regarding Microsoft are true but consider these point:
I run a small ISP and host many small applications /sites and have been hosting with WIN2k on a few boxs for going on 3 years and it has not crashed once... and yes I am supized too.
Maybe on huge projects things can go down, but the reality is that %99 of sites are smallish in terms of server load.
Yes, you have to buy WIN2k but it is not that expensive. Once you have that, the .NET SDK is free. Like Java there are open source IDE's out there that are nice that you can use to code. VS is not free, but still very affordable when compared to say JBuilder.
Many of the Servlet /EJB containers are not free and are far more costly than the M$ equivalent.
Security is an issue but most of the M$ security problems on the server is due to bad configuration. I am no M$ fan I just like some of their stuff. Anyway I do most (%99) of my work with Java/JSP so I am fairly well protected in the Java sandbox. :)
Vendor lock and the hidden evils of M$ products keep me in the Java world for the most part.
There reality is that WIN2k is easier for most people to work with and is very stable given most circumstances. I don't work for Ebay or amazon ...
I think that ASP.net has many nice things - a little from JSP and a little from WO's. All am saying is that with just a little bit work JSP could borrow from these good ideas.
Stef -
some reality checks (.NET)[ Go to top ]
- Posted by: Stefan Mischook
- Posted on: September 06 2002 02:32 EDT
- in response to Pete Cassetta
Hi,
Forgot one point: browser cross-browsr compatibility is really good actually. All the ASP.net controls automatically change the way they render themselves based on the target browser (or device too) if I recall correctly.
They have a concept of 'down-browser' or something like that where basically it checks to see if the browser is capable of doing certain things and renders the GUI accordingly. Take a look - it is really nice and are ideas worth stealing.
I actually borrowed some of the things they were doing and implemented them in my JSP work.
Stefan
-
some reality checks (.NET)[ Go to top ]
- Posted by: Reuben Cleetus
- Posted on: September 06 2002 09:21 EDT
- in response to Pete Cassetta
Please verify your facts before you speak.
I'm no fan of M$ or .NET, but ASP.NET controls are pretty darn good!
Not only do they render perfectly well in Netscape x.x, but also IE x.x, Opera... and even down to Cell phones! The controls automatically render themselves for the browser that is accessing them. What's neat is that the controls render the correct JavaScript for the browser as well, so that the environment provided to various clients is as close as possible to that provided to the richest clients.
ASP.NET controls beat the pants off anything I have seen in JSP or any open source project. All this business of Tag Libraries is bullshit!! It is the most user-unfriendly way to go about things. Please, the era of GUIs is firmly here, and is not going away.. so why does Java constantly drag you back to doing unintuitive crap to get your app working?!
Sun, please take a page from Microsoft, and copy ASP.NET controls. Yes, that's EXACTLY what the market needs -- not another framework. Frameworks are fine for academic discussions, but in the real world, we need SOLUTIONS that are EASY to implement, FAST to get to market, and COST EFFECTIVE compared to competing products.
-
some reality checks (.NET)[ Go to top ]
- Posted by: Eugene Bloss
- Posted on: September 06 2002 12:45 EDT
- in response to Reuben Cleetus
-
JSF and Sun[ Go to top ]
- Posted by: Arjuna Chala
- Posted on: September 06 2002 14:35 EDT
- in response to Eugene Bloss
I think we are all forgetting that the spec expert group consisted of companies like IBM, Borland, SilverStream, Oracle, Apache etc. These are the same companies that have produced some of the best IDE's that are in use today.
To make my point, I think people who want .NET like features should just wait for the next release of the Java IDE products from Borland, IBM, Oracle etc. They will not only me microsoft beaters but will also compete to bring out JSF control integrations that should beat .NET (At least I hope so :).
Also, before you start hopping on to Microsoft's .NET wagon consider the strong foundations of J2EE(EJB,JSP,Servlets,JMS,Web Services,JCA) and the number of companies that have invested in it and backed it.
-
some reality checks (.NET)[ Go to top ]
- Posted by: Pete Cassetta
- Posted on: September 06 2002 13:11 EDT
- in response to Reuben Cleetus
"Please verify your facts before you speak."
The online .NET demos I've seen don't degrade gracefully. Lots of functionality is lost on a browser like Netscape 4.76, and the display is quite messy. For example, visit this page in Netscape 4.76:
http://samples.gotdotnet.com/quickstart/aspplus/samples/webforms/ctrlref/webctrl/ImageButton/VB/ImageButton3.aspx
The generated JavaScript doesn't function at all, and there's an extra border sitting below the middle image.
In my own work I find I can get excellent cross-browser support by using well-written JavaScripts (e.g., many of the scripts at http://www.dynamicdrive.com). So I assume the poor cross-browser functionality is a result of Microsoft not targeting these browsers at all or doing so half-heartedly.
If I'm mistaken and you want to direct me to an online .NET demo which runs well on Netscape 4.x, please feel free to do so.
"ASP.NET controls beat the pants off anything I have seen in JSP or any open source project."
Again, maybe the demos I've seen are not showing off .NET at it's best, but I have seen comparable or more impressive stuff in the Java world at sites like:
http://www.kobrix.com/ticl/examples/index.jsp
http://wingsdemo.mercatis.de/wingset/WingSet/
http://echopoint.sourceforge.net/(Download and install their WAR for a real running demo)
Some of these have cross-browser issues, admittedly. -
some reality checks (.NET)[ Go to top ]
- Posted by: Stu Charlton
- Posted on: September 08 2002 17:06 EDT
- in response to Reuben Cleetus
"ASP.NET controls beat the pants off anything I have seen in JSP or any open source project. All this business of Tag Libraries is bullshit!! It is the most user-unfriendly way to go about things. Please, the era of GUIs is firmly here, and is not going away.. so why does Java constantly drag you back to doing unintuitive crap to get your app working?!"
So far the only difference anyone has suggested about JSP tag libraries vs. ASP.NET controls is the use of XML tag library descriptors. Otherwise, they're almost identical.
It's the intent of JSF to make them more usable in an IDE environment, which is exactly what you're asking for.
"Not only do they render perfectly well in Netscape x.x, but also IE x.x, Opera... and even down to Cell phones!"
JSF RenderKits are meant to do this.
Again, you're complaining about a spec that addresses all of your problems. The issue (and there are several, but the main one) is that it hasn't been implemented in an IDE yet. Which you can't fault the spec authors for. Maybe the Java community process for taking so long to come up with the idea. -
More on WebObjects[ Go to top ]
- Posted by: Stu Charlton
- Posted on: September 08 2002 17:03 EDT
- in response to Stefan Mischook
"One thing that leaps to mind is the stupidness of needing 2 different JDBC drivers; one for EOF and another for Project Builder ... How about all the class path issues. With Resin for example, to get it going takes all of 1 minute. It gives me the shakes when I think of the time it took me to get WO's up. I have to say though that Apples support was pretty good."
WO5 on Windows has some idiosyncracies, mainly because Apple's focused on Mac OS X. I agree with this one.
"Project builder/ WO builder (Windows version) reminds me of windows 3.0 applications."
The Project builder isn't my favorite tool, but the WO builder? It's pretty slick in my experience.
"It has been a while since I looked at it. I think though the biggest time saver is EOF. But on the other hand it can get pretty slow ..."
Not really, if used right (like most O/R mappers).
"The code counting stuff does not mean much, you can do the pet store with much less code is a JSP / bean combination with container load balancing ect... by just leaving out the EJB stuff."
The JSP/bean/SQL combination is what some have tried to do, and it's still quite bulky compared to the WebObjects approach. Hand-crafting SQL for every use case means quite a lot, thank-you.
"Yeah, maybe if I spent a few months on it I could get productive but I spent a couple of days on JSP and things came along nicely."
Hey, if you problem is so simple that it just takes a couple of days with JSP, more power to you! I'm talking about harder problems, that take months in JSP, vs. weeks in WebObjects.
"I know WO people have a lot of passion about the product and seem to be inclined to resorting to insults (ex:I just assume you were one of those people that dropped out of highschool math because "it's too hard and gains me nothing". )"
I found your original post highly insulting "WebObjects is the buggiest piece of crap I've ever used". So naturally, I can either assume that a) you're a troll, or b) you're ignorant.
Now that you've detailed your experiences, I can see that you're c) don't need WebObjects because JSPs suit you fine.
Which is fine with me.
"I look at these things as tools, like a hammer - I don't get emotional about it because frankly I don't really care."
It amuses me when people suggest that someone is "being too emotional" over a topic. Any task that's worthwhile, that you enjoy and pride yourself in accomplishing, it involves emotion. Engineering especially. And when you engineer great solutions in no small part due to a particular framework, it's natural for an emotional reaction to occur when someone says it sucks.
So frankly, I think you're not being emotional enough. Suggesting that you "really don't care" about the tools of your trade reflects poorly upon your professional judgement.
For the record, I'm not a regular WebObjects user anymore, I'm not a NeXT or Apple zealot, I just happen to be someone that is going to defend a framework that is often leveraged to create higher quality solutions than most of what's turned out of raw JSP/Servlet solutions. I do this so we can *learn* from WebObjects and apply it to the J2EE world in future products and design principles.
-
some reality checks - er[ Go to top ]
- Posted by: Robin Sharp
- Posted on: September 08 2002 04:56 EDT
- in response to Stu Charlton
Qualm: "No tables. No trees. No menus. No swapable look and feels to PDF/XML/JFC. No nice chunky demos to rub the .NET'ers faces in. Basically no beef. If anybody was hoping for Sun to provide a competitor to the .NET Web Components they're going to be let down. "
Retort: This is like complaining to Ferrari that they don't make school buses. Your expectations were WAY out of line of ANYTHING that's come out of the JSF spec request.
Ha Ha: You're clearly in a *deep* state of self denial believing that JFC compares to Ferrari whilst a rich set of application components compare to school buses. -
Reaction to JSF hype[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: September 08 2002 10:35 EDT
- in response to Robin Sharp
There's this amazing paradox involving JSF.
JSF hype: Amazing components with client side everything.
JSF spec: Forms support.
If you complain that the spec doesn't meet the hype you are alternately lambasted for expecting too much (JSF does exactly what's in the spec ... which only went public last week) or you are lambasted for ignoring the hype (it's just an early release, wait til you see what's behind curtain #2).
Can anyone name ONE area where Sun coopted an existing technology and improved on it? Is CORBA improved because Sun moved the APIs into the JRE? Is Log4J improved because it became javax.logging (or is it just the opposite). Jakarta ORO and javax.regexp. It's called Not Invented Here syndrome and its dangerous. -
Reaction to JSF hype[ Go to top ]
- Posted by: Stu Charlton
- Posted on: September 08 2002 16:49 EDT
- in response to Howard Lewis Ship
"lambasted for ignoring the hype (it's just an early release, wait til you see what's behind curtain #2). "
What hype, other than community-generated rumor? The only things coming out of the JSF committee that I recall were the JavaOne presesntations in 2001 and 2002, both of which were relatively disappointing in that they said they were aiming to do exactly what's in the spec today. Perhaps there's a whitepaper I missed. -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Ivelin Ivanov
- Posted on: September 07 2002 22:16 EDT
- in response to Floyd Marinescu
Does somebody know if there are plans for JSF compliance with the W3C XForms standard? -
My JSF critique[ Go to top ]
- Posted by: Stu Charlton
- Posted on: September 08 2002 17:41 EDT
- in response to Floyd Marinescu
So, after a once-over of the spec, here are my thoughts.
In short, JSF is promising, but has some glaring problems that really need to be fixed. I'll be forwarding this to jsr-127-comments at jcp dot org.
- JSF is very similar to ASP.NET's server controls in both intent and in the way they are rendered to a response page. Note I am not talking about ASP.NET *user* controls, but the heavyweight server controls.
- The binding of control to the model looks promising, very similar to ASP.NET's databound controls and WebObjects .wod files.
The not so good (recognizing it's pre-beta, but still):
- The Cardemo example is gross. You spend more time doing inexplicable byte-level copies of JPGs than showing off JSF. Though only logical thing I could gather was that UIGraphic isn't ready to use yet, so you wanted to emulate similar behavior -- but wound up with something that's confusing and almost silly since you could copy the URL to the image instead of the image itself. It's as if almost no thought was put into this demo, and was whipped up on a weekend. I 'm sorry about the rant if there's something I'm missing about this.
- The default ServletContextListener code to initialize faces really should be included in the framework, so I can override or delegate to it if need be. The explicit factory lookups seem unnecessary for the majority of cases.
- ApplicationHandler seems like it could become a maintainence nightmare on many levels, if I'm understanding it correctly.
a) I have to recompile that class for EVERY page I add to the site, and every new form/command.
b) A huge if-else statement to intercept events? I thought we moved away from this after JDK 1.0. Some potential/better solutions:
- Allow the UICommand to register an event handler, which could be any arbitrary object implementing a CommandEventHandler interface OR if you're feeling adventurous, any arbitrary method conforming to a particular signature.
- Provide a command name -> next tree configurative mapping like struts-config.xml
c) The tree dispatching code (the whole find tree factory -> setResponseTree stuff) appears to be redundant and should be placed in the framework to simplify the majority of cases.
In short, there's not a lot of layered abstraction going on with JFC. It arguably exposes too much to the application developer in order to handle events. Now the only thing I can think of is that the ApplicationHandler is going to be something that an IDE will generate. Fair enough, but I guarantee people are going to want to modify that code for complex dispatching scenarios, where there is no deterministic "next tree", some validation and/or logic must be executed first.
I guess the principle I'm suggesting is that JSF should make it transparent to use the basic most widely used stuff, and then provide the layers of abstraction that let me dig down into the bag of tricks if I need to.
Cheers
Stu
-
THE GOOD OLD GUI FRAMEWORK TOPIC[ Go to top ]
- Posted by: Robert Stindl
- Posted on: September 12 2002 10:53 EDT
- in response to Floyd Marinescu
Hi Folks,
i considerd to ask the community why the gui framework topic is that hot and i also wanted to tell you my opinion about a real complete gui framework, but just take a look at:
Cassandra - http://sourceforge.net/projects/cassandra
its just groovy,
jimi -
THE GOOD OLD GUI FRAMEWORK TOPIC[ Go to top ]
- Posted by: Sankar B
- Posted on: September 16 2002 09:39 EDT
- in response to Robert Stindl
Hi All,
I dont care about EJB, since our web applications really doesnt need EJB and our clients are not ready to buy App Servers. (Even Gartner Report says 60-70% of the so called J2EE Applications developed till now all over the world use only JSP. Rest of the 30-40% only are in EJB).
Without EJB we developed nearly 5-6 Web Products full of JSP only without any framework. Now weve seen ASP.NET and developed few Mobile Applications and Web Applications in ASP.NET.
1. Our Mobile Application developed in ASP.NET and deoployed in IIS 6 with Mobile Tool Kit can be viewed in more than All Handsets
(Keep in mind no mobile application will be like c/server ERP app's)
How long will it take for Sun and others to give such a Framework or something (Mobile Tool Kit) and a Free Server (like IIS). Another 5 Years ?
2. We are able to develop ASP.NET Web Services in no time. And we deployed for production also. We are able to use it in Java with AXIS.
How long will it take for Sun to give ASMX like pages. Though AXIS is there, Y Sun is not using it. Even it didnt support Struts also. But come out with JSF with same functionality.
3. We are able to develop ASP.NET projects as fast as ASP OR JSP or Even an Windows Application or Java Application using the Controls.
JSF has no way comparable with ASPX HTML Controls. Will Sun take another 1 year to develop such controls. Even JSF will take another year for release.
4. ASP.NET Server Controls like DataGrid have minimised the development of web projects drastically.
Will Sun gives such a Server Control atleast within a Year.
5. ADO.NET gives back the table data itself as XML and the Disconnected DataSets will definately be useful.
Can we think of anything in near future from Sun.
6. Custom UI Controls can be developed in no time.
Sun, Did u heard about anything like this.
7. .NET is not available for Linux.
Beware, www.mono.org will give the answer within 3 to 6 months.
Im asking, Apache is only for Java Development. Y dont Apache get in to .NET and develop a C# Compiler, .NET CLR, and other libraries for Linux in Open Source. If they get into it, they can do the things within 3 months time, with the help of Such a big community support. Y not Apache Team think about it.
8. Support for Oracle, SQL Server, and other OLEDB based DB's are supported in .NET or even the DB Vendors are releasing their own Data Providers for .NET. Ex: Oracle Data Provider for .NET
9. Multiple language Support. Definately in big organisations, VB developers, C++ developers and new to MS developement from Java guys like us can learn within few days C# and get in to .NET development. They individually can develop the libraries. But can be used, utilising the entire developer resources without the barrier of language.
Sun is not able to support Java itself. They are so busy people.
10. ASP.NET application are really faster than JSP.
Still and even after 2 or 3 years also, Sun cannot give a JVM without Memory Leak.
Its upto u to decide. Java guys dont get angry on me. Cos, Its my experience ive wrote here. Im not blaming others. Bye
Thanks,
Sankar.B -
THE GOOD OLD GUI FRAMEWORK TOPIC[ Go to top ]
- Posted by: Jochen Krause
- Posted on: September 20 2002 12:11 EDT
- in response to Sankar B
Hi Sankar,
not that I am happy with everything in JSF (and the time things take), but nevertheless I want to give you a couple of short responses to your statements:
1. a free server for JSP stuff - could be tomcat (and this one is free!)
mobile toolkits can be addressed as renderkits in JSF
3. third parties will be fast on providing server side controls (see what can be achieved at http://www.innoopract.com/ebuyer/
I agree that jsf expert group should speed up a lot
4. see 3.
5. Disconnected DataSets = Rowsets in Java but no xml :-(
6. Custom UI Controls - Still room to improve in JSF, but I just don't want to imagine that they fail to deliver this
7. MONO - they are able to do command line stuff for now - after one year. The GUI stuff is the though task
8. I agree that jdbc drivers should be better, but they are improving. I wonder if the oracle OLEDB drivers are better than the JDBC ones ?-;
9. good point - but many "expert" opinions if this is really wishful (maintainance)
10. this might be true, but is it really the presentation layer which makes up for the speed in your apps (business logic??)
There is a gap to close with regards to rich html frontends, and there is absolutely no time to loose for JSF.
But I prefer choice over time to market speed. Is is up to you to decide!
Cheers
Jochen
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Vic Cekvenich
- Posted on: September 17 2002 22:25 EDT
- in response to Floyd Marinescu
I would be sad for any clients that did JSF the way it is now, since I think those clients will go to .NET controls soon. (Same as EJB, anyone who uses EJB goes to .NET ADO next year).
I am looking forward to Oct. 8th:
http://developer.java.sun.com/developer/community/chat/
I hope to hear that they will start from scratch and that http://www.qbizm.cz/newsletter.html was a mistake and it will do opposite from that.
Why JSF might not consider these comments?
Because applets provide the GUI. (Of course no one does this or should use Java on Client Side.) So in order to “promote� Java applets client side, lets not do rich GUI, since they can always do WebStart.
As a consultants I advise against applets, they are slow, hard to deploy, etc. etc.
What clients want for JSF is things like http://www.salmonllc.com/website/Jsp/vanity/Jade.jsp?nav=5
Or Koribix.com or JSTL…. But it must emit JavaScript for GUI.
Rich GUI means tags that emit JavaScript!
Maybe support XHTML so people could XSLT (on browser side XSLT to other formats)
What is minimum JSF could do?
Make Struts the reference application! It must be MVC (Servlets and JSP should have a reusable bean defined outside of JSP or Servlet – This should be a part of JSP and Servlet specs)
Require that a J2EE compliant editor must expand the tags like Dream Weaver or IBM editor do. (This way Eclipse and NetBeans will offer it).
What would be nice for JSF to do?
Provide client side controls, like .NET, (tags that emit JavaScript, Tree, drop down, move to from list box to list box, )
What would be even nicer?
A .NET ADO. Such as a DAO interface that JDO, and OJB (Jakarta) and Expresso or JDBC RowSet could implement, so people could chouse persistence.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/basicportal/src_05d/basicPortal/src/org/apache/commons/DAO/BasicDAO.java?rev=1.2&content-type=text/vnd.viewcvs-markup could be implemented by most.
And then you could have a bean generator, where you enter a SQL command as a string and the IDE writes the getters and setters.
(Why not do this for JSF? EJB! Of course most clients throw out EJB )
OT:
I now think Sun is “gone� company and best thing for Java is that Sun goes away sooner. There is IBM VM, JRockit, TowerJ, many compilers and open source Java.
Sun can’t sell SW and has slow HW.
I recommend clients avoid Sun HW and Sun Java.
Vic
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Sankar B
- Posted on: September 18 2002 04:48 EDT
- in response to Vic Cekvenich
Hi
What I expected was something like Applet, but lightweight which can run without a browser itself, and a somewhat similar functionality of combination of Midlet and Applet and which can run with a small program like Java Web Start or something else. Cos, Browser is not an environment which can run Applications like C/S. I thought if we develop once, it can be run in PC's and Small Devices as well, with some XSL implementations for each devices. So that for each Browser, Cell Phones, PDA's, with each XSL, the same application can be used.
All my Expectations are gone now. But, with Mobile Internet Tool Kit, MS has done this. Infact we dont need to develop the libraries for each device. They release Device Updates, which will convert the same ASP.NET pages to render in different pages. Even we can run C#.NET Windows Forms can be run from Internet or Intranet, without a browser as C/S. Even Oracle is using 9iForms deployed in 9iAS which ofcourse uses browser as a starting point, and deploys the Forms application as an Applet. But, again its not possible to render them in Small Devices.
My best advise is, Make Swing to support XSL for rendering. Based on the XSL reference and the Requested Device, Swing can be used extensively without these JSP, JSTL, JSF all these etc. frameworks.
Ive even seen a doc about droplets in Sun site once a month back.
But that too is not for all the Devices based on XSL. See its simple, I dont know y these people at Sun are not thinking about Rendering the Front End and the Front End Components. They concentrate more in Back end and Midlleware to encapsulate Business Logic seperately from Back end db. Same way, y dont seperate the Front End components and Rendering seperately which definately solves the probs. Encapsulating the Front End Components like the Entire Page design itself which will have text box, button, links etc. The Rendering Components may be XSL or something else which can takecare of front end validations and size of the Front End Components. So different Rendering Components can be developed based on the Browser, PDA's, Cell Phones, etc. But the Front End Component can be developed with Swing Like Components, but with Different Rending Components make it possible for using the same Front End Components to use for Client/Server, Browser, PDA's, Mobiles, etc. etc. So that, the Front End Components can be designed with IDE's or Tools like Visual Studio/Forte/JBuilder etc. and can be rendered using the Rendering Components.
Is is a Viable Idea or not...
Yours,
Sankar.B
Information Dynamics, Chennai, India
U can see my posting in this forum expressing my dissatisfaction:
http://forum.java.sun.com/thread.jsp?forum=427&thread=300444
and
http://forum.java.sun.com/thread.jsp?forum=427&thread=300386
-
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: Vic Cekvenich
- Posted on: September 18 2002 17:13 EDT
- in response to Sankar B
For what it is worth:
After looking at the actual code examples vs the early rumors and speculations and my jumping to conclusions, I found MUCH to like about the actual JSF samples posted in Developers Connection Early Release.
My apologies for the prior flame posts!
basicPortal for one will deprace the the html tag in favor of the h tag asap (it already does not use logic or bean tags in favor of JSTL).
Again, please allow me to reverse 180, I found much to like in JSF samples, and will try to be an early adapter and have a few early clients on it (some of my clients have VERY large # of concurrent users, much more than 10,000 concurrent users on Struts).
We should have a JSF with DAO example very soon on sourceForge.
Vic
(I am curios about multi row updates, multi row validation, I warped my beans with collections in past to get MasterDetail working;
Also, I wish validation was in the bean, since bean could be used by services, SOAP, etc. and you want client side validation outside of JSP, but.... let me shut up, but I can hardly wait for the Struts-JSF jar) -
Java Server Faces Public Draft and Early Access Available[ Go to top ]
- Posted by: jp fielding
- Posted on: September 22 2002 10:26 EDT
- in response to Floyd Marinescu
Even though I am completely disappointed with what I've seen in the ea release of JSF, I would have no problem with it if it was truly an 'open' 'community process'. But it's not. People talk about 'two years of Web GUI components and too many of them around'... well where was that (two years * too many frameworks * number of developers) expertise when it came time to implements it? Not invited. (Hey is Dick Cheney hiding with you guys?)
I personally hate JSP. I feel that the industries many GUI framworks for stdio have all converged (relatively) for a reason, that reason is that it has proven best. I feel that using tags for the web, just because they look like the underpinnings (html) would be like developing thick client apps with a pixel based language. To quote Chris Rock, 'you can drive with your feet, but that doesn't make it a good idea'.
The worst part is that a compromise exists. If you start with a web component framework like Echo, you can then go back and write a tag lib that wraps it. Everyones happy.
If it ends up not satisfying the whole community, it will simply splitter the community even farther.
Good Luck with the rest of the implementation. I hope that it ends up closer to it's original goal of being somewhere between Servlets and JSP. If not, the other half of the community will continue down existing paths until IBM makes the standard that will address both sides of the problem.