Java Server Faces Public Draft and Early Access Available

Discussions

News: Java Server Faces Public Draft and Early Access Available

Bookmark and Share Get thread feed

  1. Java Server Faces Public Draft and Early Access Available (118 messages)

    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
    Reply to this

    Threaded Messages (118)

  2. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    Where can we find more documentation on JSF?
    Reply to this Reply to original

  3. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    Have you downloaded the java server faces tutorial?
    It's a 53 pages pdf.
    Reply to this Reply to original

  4. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    I only know the online. Where's the PDF?
    Reply to this Reply to original

  5. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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...
    Reply to this Reply to original

  6. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.


     
     
    Reply to this Reply to original

  7. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  8. But is JSF component based?[ Go to top ]

    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
    Reply to this Reply to original

  9. But is JSF component based?[ Go to top ]

    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?
    Reply to this Reply to original

  10. Tapestry Postings[ Go to top ]

    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.




    Reply to this Reply to original

  11. But is JSF component based?[ Go to top ]

    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
    Reply to this Reply to original

  12. Porlet API[ Go to top ]

    I'm sorry ... I don't have an opnion; I haven't read it. Perhaps I should.
    Reply to this Reply to original

  13. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    "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.
    Reply to this Reply to original

  14. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    "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.
    Reply to this Reply to original

  15. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  16. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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!
    Reply to this Reply to original

  17. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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!
    Reply to this Reply to original

  18. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.

    Reply to this Reply to original

  19. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    Take a look at The JADE Open Framweork http://sourceforge.net/projects/salmon. It's what JSF should have been.
    Reply to this Reply to original

  20. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.



    Reply to this Reply to original

  21. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  22. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    If you really want trees, split panes and pop up menus take a look at Flash Remoting http://betaprograms.macromedia.com,
    Reply to this Reply to original

  23. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  24. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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>!
    Reply to this Reply to original

  25. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  26. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  27. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  28. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  29. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  30. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  31. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  32. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  33. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  34. THE CRAPPIEST AND RIDICULOUS SPECIFICATION OF SUN[ Go to top ]

    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.
    Reply to this Reply to original

  35. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  36. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  37. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    HA HA! Pierre Loire's right!! The page (GLUE) is written in ASP.NET, using C#, no less!!

    :)
    Reply to this Reply to original

  38. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.

    Reply to this Reply to original

  39. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    Download page is served from a different server. Possibly some kind of hosting arrangement, otherwise makes no sense to me.

    -- Igor
    Reply to this Reply to original

  40. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  41. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  42. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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?
    Reply to this Reply to original

  43. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    "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.

    Reply to this Reply to original

  44. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  45. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    so we agree not complete & not bad
    Reply to this Reply to original

  46. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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).
    Reply to this Reply to original

  47. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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?
    Reply to this Reply to original

  48. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  49. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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?
    Reply to this Reply to original

  50. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.



    Reply to this Reply to original

  51. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  52. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  53. The Problem with Tapestry...[ Go to top ]

    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.

    Reply to this Reply to original

  54. The Problem with Tapestry...[ Go to top ]

    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.
    Reply to this Reply to original

  55. The Problem with Tapestry...[ Go to top ]

    Funny. "Rabidly" may be accurate, but I mean "rapidly.".
    Reply to this Reply to original

  56. Tapestry with JSP[ Go to top ]

    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.
    Reply to this Reply to original

  57. Tapestry with JSP[ Go to top ]

    Would go a long way to increasing adoption imho.
    Reply to this Reply to original

  58. Tapestry with JSP[ Go to top ]

    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.
    Reply to this Reply to original

  59. Tapestry with JSP[ Go to top ]

    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.
    Reply to this Reply to original

  60. Tapestry with JSP[ Go to top ]

    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).
    Reply to this Reply to original

  61. Tapestry install problems[ Go to top ]

    you are wrong Howard. Tapestry does not install under jboss3.0, which by the way does not work with JDK 1.3 and higher.
    Reply to this Reply to original

  62. Tapestry install problems[ Go to top ]

    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.
    Reply to this Reply to original

  63. Tapestry -- Getting Right JBoss Version[ Go to top ]

    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.
    Reply to this Reply to original

  64. Tapestry with JSP[ Go to top ]

    "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.
    Reply to this Reply to original

  65. No capable leaders[ Go to top ]

    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.
    Reply to this Reply to original

  66. Tapestry with JSP[ Go to top ]

    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.
    Reply to this Reply to original

  67. Tapestry with JSP[ Go to top ]

    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.
    Reply to this Reply to original

  68. Tapestry with JSP[ Go to top ]

    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!



     
    Reply to this Reply to original

  69. Tapestry with JSP[ Go to top ]

    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.
    Reply to this Reply to original

  70. Tapestry with JSP[ Go to top ]

    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.
    Reply to this Reply to original

  71. Tapestry with JSP[ Go to top ]

    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
    Reply to this Reply to original

  72. No Problem with Tapestry...[ Go to top ]

    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.
    Reply to this Reply to original

  73. No Problem with Tapestry...[ Go to top ]

    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.
    Reply to this Reply to original

  74. No Problem with Tapestry...[ Go to top ]

    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>
    Reply to this Reply to original

  75. Tapestry thread[ Go to top ]

    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.
    Reply to this Reply to original

  76. No Problem with Tapestry...[ Go to top ]

    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
    Reply to this Reply to original

  77. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  78. Problems with JSF[ Go to top ]

    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.

    Reply to this Reply to original

  79. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  80. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  81. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  82. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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

    Reply to this Reply to original

  83. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  84. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    Finally a sensible comment ;)

    Boris
    Reply to this Reply to original

  85. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  86. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    "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.
    Reply to this Reply to original

  87. SOMEONE ASKED ABOUT HOW JSF COMPARES TO .NET ???[ Go to top ]

    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~
    Reply to this Reply to original

  88. SilverStream had Web Components with IDE Integration YEARS ago[ Go to top ]

    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.
    Reply to this Reply to original

  89. And dont forget Apple WebObjects[ Go to top ]

    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.
    Reply to this Reply to original

  90. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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 :-))
    Reply to this Reply to original

  91. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  92. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    The framework is in pre-beta. Drop me a line to imeshev at yahoo dot com. I'll include you into release announcement list.
    Reply to this Reply to original

  93. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  94. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original

  95. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  96. Wings (to fly with)[ Go to top ]

    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
    Reply to this Reply to original

  97. some reality checks[ Go to top ]

    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
    Reply to this Reply to original

  98. some reality checks[ Go to top ]

    .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
    Reply to this Reply to original

  99. some reality checks (.NET)[ Go to top ]

    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.
    Reply to this Reply to original

  100. some reality checks (.NET)[ Go to top ]

    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
    Reply to this Reply to original

  101. some reality checks (.NET)[ Go to top ]

    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



    Reply to this Reply to original

  102. some reality checks (.NET)[ Go to top ]

    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.
    Reply to this Reply to original

  103. some reality checks (.NET)[ Go to top ]

    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

    maybe it is not so dramatic :). Check out for example
    Coldtags
    or TICL

    Yes, we do .NET programming also, so I can compare ...
    Reply to this Reply to original

  104. JSF and Sun[ Go to top ]

    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.

    Reply to this Reply to original

  105. some reality checks (.NET)[ Go to top ]

    "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.
    Reply to this Reply to original

  106. some reality checks (.NET)[ Go to top ]

    "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.
    Reply to this Reply to original

  107. More on WebObjects[ Go to top ]

    "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.

    Reply to this Reply to original

  108. some reality checks - er[ Go to top ]

    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.
    Reply to this Reply to original

  109. Reaction to JSF hype[ Go to top ]

    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.
    Reply to this Reply to original

  110. Reaction to JSF hype[ Go to top ]

    "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.
    Reply to this Reply to original

  111. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    Does somebody know if there are plans for JSF compliance with the W3C XForms standard?
    Reply to this Reply to original

  112. My JSF critique[ Go to top ]

    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
    Reply to this Reply to original

  113. THE GOOD OLD GUI FRAMEWORK TOPIC[ Go to top ]

    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
    Reply to this Reply to original

  114. THE GOOD OLD GUI FRAMEWORK TOPIC[ Go to top ]

    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
    Reply to this Reply to original

  115. THE GOOD OLD GUI FRAMEWORK TOPIC[ Go to top ]

    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

    Reply to this Reply to original

  116. Java Server Faces Public Draft and Early Access Available[ Go to top ]


    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



    Reply to this Reply to original

  117. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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
    Reply to this Reply to original

  118. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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)
    Reply to this Reply to original

  119. Java Server Faces Public Draft and Early Access Available[ Go to top ]

    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.
    Reply to this Reply to original