This is a new column and Chuck's here to answer Java programming questions. Are you curious about a technology or a technique? Ask here and your question may appear in a future column.
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 19 of 19.

• Java page flows
  2003-09-26 21:22:06  anonymous2 [Reply | View]
  
  
  has anyone tried this? i think it is in bea's weblogic workshop.

• Test
  2003-09-03 21:06:15  myshkin5 [Reply | View]
  
  
  Test
  one
  two
  three
• Test
  2003-09-19 20:44:58  anonymous2 [Reply | View]
  
  
  dont test

• MVC View raising events?
  2003-09-01 09:28:36  anonymous2 [Reply | View]
  
  
  As I understand it this would be achieved using call-backs. That positions JSF as *another* hurried (read harried?!?) catcher-upper/filler technology.
  
  Also, as someone else mentioned previously, the ball-park is once more being opened for vendor-specific lock-in around various components. Historically this has shown me that it impacts cross-platform capability.
  
  Clearly these are issues around JSF. Even more concerning for me at this juncture is that JSF brings me no closer to a consistent model for coding/architecting the UI, business logic and data logic. Acronym + paradigm = relearn for each app layer, per vendor!
  
  Losing a little faith here :-)
  
  Mike Wittenburg

• Nice comments, but...
  2003-07-25 13:34:10  chuckcavaness [Reply | View]
  
  
  Can’t say that I disagree with all of the comments here, but some are pretty biased. As far as JSP and Tags being a “big ugly kludge” and a mistake, I would agree there are some issues but someone might want to inform the thousands of applications built and running using these technologies; successfully I might add. I know, I know, there are also many applications implemented with CGI, or Active Server Pages, or other non-perfect technologies. My argument doesn’t necessarily make JSP good. But read on.
  
  Here’s the problem as I see it. I want a UI technology where I can describe a UI separately from other aspects of the architecture, like business objects or data access layer. Have the UI architecture work for multiple channels, Web, Rich Client, Handheld, etc. and provide all of the typical features that as developers, we’ve come to expect (localization, session management, security, validation, etc). And I want a consistent, portable approach. Note that I didn’t say a standards-based approach. Although I think that inevitably an approach based on standards is beneficial, it doesn’t bother me that if in the beginning there are no official standards if this helps to move the innovation along. Look at Struts and its popularity. There were no standards for its Tags for example until JSTL came along. This is fine with me.
  
  However, we have to solve the problems I mentioned above. Just as people are tired of trying to decide what persistence mechanism to use for every new project, choosing a UI framework shouldn’t be so difficult. However, I’m perfectly ok with letting the market settle that question. Regardless, I haven’t seen a solution that’s perfect; each one comes with it’s own scripting language or framework oddities. Why is choosing the best of all and combining into a single approach bad if it simplifies development and gets product to market faster?
  
  So, whether it’s JSF or some other technology or whether Sun and company develops it or it comes out of the Apache birthing ground, I don’t care. The important thing is that we keep the innovation moving forward and don’t settle on where we are currently at as an industry. It’s just not enough for large, multi-channel, enterprise-class applications.
• Counterpoints ...
  2003-07-25 13:57:48  hlship [Reply | View]
  
  
  First off, there's a myth about the "pluggable, skinnable" UI ... that the difference between a desktop/browser UI, a rich UI and a cell-phone UI is just a matter of paring down the interface.
  
  I've found this to be anything but the case; these different interfaces are funamentally different applications ... new use cases, new storyboards, different functionality. Trying to leverage reuse in the UI is a terrible idea; the end result (whether using JSF, XML/XSLT or something else) is to increase unwanted interdependencies between these fundamentally different applications ... it's programming inside a big case statement and will simply not scale.
  
  Reuse is best reserved for the application layer (EJBs and beyond).
  
  Main point:
  
  
  "Why is choosing the best of all and combining into a single approach bad if it simplifies development and gets product to market faster?"
  
  Where did this statement come from? Under what circumstances is JSF an integrating approach? JSF is anything but ... it locks you into a very specific event cycle and requires extensive tools support. Additionally, each vendor is likely to provide vendor-specific JSF components; it's the only lockin they have left.
  
  More importantly, there's no evidence that JSF is capable of being the kind of integration technology that would allow developers to choose the best. It is something of a least-common denominator choice, partly because it is bound to JSPs, a limited and problematic technology.
  
  You are right that no Technology will address every need but I feel that Tapestry is better positioned than JSF to address real developer's issues. Tapestry works very well as an integration platform for varied technologies because so much of it is based on JavaBeans properties (and OGNL, a vastly superior expression language).
  
  
  

• JSF (JSR 127) was started two yers ago
  2003-07-25 03:08:59  anonymous2 [Reply | View]
  
  
  ...it is very, very slow work ...is it good work? :) ...yes! for Microsoft .NET

• View separation
  2003-07-24 06:50:57  anonymous2 [Reply | View]
  
  
  "First of all, there's still not a complete separation of UI from the model. UI designers still have to have some programming knowledge"
  
  Have we ever had this mythical separation, even in fat clients? MVC allows for optional views to be plugged in, but the intent was never to remove the need for at least some programming knowledge. How would we have MVC with smalltalk and Swing without having some programming knowledge? Ironically, it's JSF that seems to break this ideal by requiring the action listeners to be specified, full class path and all, in the JSP page. Even Struts didn't require that.
  
  What needs to be said about JSF is that it is intended for GUI builder tools. Its benefits won't be clear until at least on vender has the tool ready.
  
  Tayor Cowan
• View separation
  2003-07-27 12:43:01  anonymous2 [Reply | View]
  
  
  "What needs to be said about JSF is that it is intended for GUI builder tools. Its benefits won't be clear until at least on vender has the tool ready."
  
  That's what I fear the JSRs and JCP have become about: A way for vendors to propose overly complex "standard" that are impractical to hand code, so they require you to use tools that they just so happen to be more than willing to sell to you.
  
  This ridiculous shunning of simplicity in pursuit of "standards" and design by committee tempts me to take a peak at what .NET is all about. Having work with excellent "non-standard" tools, like WebObjects, leads to believe that proprietary can be much better than what comes out of committee.

• Why Sun?
  2003-07-24 04:01:42  jimothy [Reply | View]
  
  
  Why does this have to come from Sun? Why does it have to be a JSR? Couldn't a equally good--or better--solution come from Apache, IBM, or some other player in the Java space?
  
  The problem I have with Sun and JSRs is that they try to throw everything, including the kitchen sink, into a specification and wind up with something that is overly complex and doesn't serve developers' needs as well as products already on the market, or that might have soon come to the market. And yet, they end up effectively killing those competing products because the result of the JSR becomes "the standard."
• Why Sun?
  2003-07-24 08:08:38  anonymous2 [Reply | View]
  
  
  What are you talking about? It's not just Sun. It's a JSR, which comes from the JCP -- have you looked at the list of contributors to the JSR 127 (JavaServer Faces)? I see IBM, Macromedia, Oracle, Siemens, Fujitsu, HP, and more.
  
  The reason why "everything and the kitchen sink" gets thrown into a JSR is not necessarily because of Sun -- more likely it's because the JSR will never get approved unless each entity involved in it gets a piece of the pie (has some feature that is crucial to their agenda).
• Why Sun?
  2003-07-25 20:15:26  anonymous2 [Reply | View]
  
  
  "I see IBM, Macromedia, Oracle, Siemens, Fujitsu, HP, and more."
  
  And what web app frameworks have they built? Oh, wait... none. Craig built a web app framework, and created about the biggest pile of inflexible code I could imagine.
  
  JSF is weak, and yet tools will be supporting it and it will be called the "standard" for building web applications in Java. Shame on the JCP for this setback.
  
  Jason Carreira
• Why Sun?
  2003-07-28 06:02:20  jimothy [Reply | View]
  
  
  "And what web app frameworks have they built? Oh, wait... none."
  
  Precisely! That's the problem, companies that have little to no experience building a framework for a particular purpose being charged with building a "standardized" framework. My guess is we'll wind up with the "biggest pile of inflexible code" all over again.
• Why Sun?
  2003-07-28 05:37:52  anonymous2 [Reply | View]
  
  
  Macromedia, IBM and Oracle are in the business of selling application servers, plus development tools, so I can see why they'd be interested in contributing to this JCP. Macromedia is also probably interested in exploring what can be done with Flash-based JSF libraries.
  
  I didn't hear that they were going to deprecate JSP or HTML, so if you don't like the idea of working with JSF, by all means don't waste your time. Also, I hear far more buzz about JSF from developers/OSS proponents than I do from vendors.

• Tapestry and JSF
  2003-07-24 00:24:43  anonymous2 [Reply | View]
  
  
  Tapestry framework looks very good. I thing, Sun could save a lot of many...
• Tapestry and JSF
  2003-07-24 07:54:21  hlship [Reply | View]
  
  
  I've been dismayed every time I've looked at JSF. You have to poor on loads of code to get anything done, there's that single event listener method for the entire app (I hope they've done something about that subsequently), and you are basically screwed without tools support.
  
  I built Tapestry to address the same problems and its easier and better than JSF right down the line; less coding, better seperation, more flexibility ... and something even more key: years of exposure.
  
  Because Tapestry didn't come out of Sun and a JSR, there was never the need to promote the myth that it was the perfect solution out of the box. Instead, I've had three years to build a community, listen to my end users, and improve the framework iteratively and flexibly. Many of my initial concepts have proven wrong in the field and I've adapted the framework to meet the real world.
  
  The basic proposition of JSF ... that developing a web application requires specialized IDEs and tools is refuted by Tapestry which works better than JSF without specialized tools. A standard WYSIWYG HTML editor is the most that you need. Spindle (the Eclipse plugin) improves productivity but is not a requirement to make use of Tapestry.
  
  I'm definately in the camp now that says the JSR concept is fundamentally flawed; you don't innovate by committee. JSF is a big ugly kludge as Sun defends its prior mistakes (JavaServer Pages, JSP tags) without acknowledging their limitations and oversights.
• Tapestry and JSF
  2004-12-04 21:16:10  jlong [Reply | View]
  
  
  I absolutely, wholeheartedly agree. I used Struts for a year. I then moved to a different company and didn't want to undertake a project (a massive project whose Hibernate domain model has literally hundreds of individual classes) in Struts. So, I tried JSF and came back with my head spinning. Nothng came of it-- though the whiz-bang feel was certainly there for the two or three useful screens we did build. Anyway, we adapted Tapestry. Tapestry has literally taken a project that was stalled in development hell for almost a year and finished it, rebuilt from the groun up, in 3 months. We built it from the ground up using Tapestry. We added things as we learned, but it was all very intuitive. First, simple forms for customer input and simple screens for reporting. Eventually, simple screens became editable screens. We added html-only, macro-style components to standardize our GUI. We then added components with more interactive, dynamic functionality like our menuing system. Many of our forms leverage the supportof Tapestry for common use cases -- use cases that most database schemas dictate. Date input is trivial with the DatePicker. Many to many relationships (ie, take a User who can be assigned many roles from many possible roles) are a breeze with the Palette. One to many relationships using drop down menus are easy AND consistantly developed. Other one-to-one, or input on domain properties which has always been easy is still easy, but now its also robust. For example, telephone numbers, zipcodes, credit cards, etc. can all be validated and guaranteed with Tapestry's validation system. Atop of all this is ridiculously easy localization (hell, it's almost easier to use the localization framework than to avoid: our manager always wants to tweak the copy displayed on various pages. So we just send him the .properties file. Easy!), easy gui development (Mr. Ship was sincere: 95% of the development for our views happens in DreamWeaver), and easy err... messaging.. that is... i haven't ONCE worked with a URL when building this application. Page flow is trivial to implement.
  
  The only other framework out there whith which I've had this experience is ASP.NET. But even there, it's not as sophisticated. .NET, out of the box, doesn't come with as many useful components (there are 3 calendars in .NET and not one of them is as sexy as the one in Tapestry.).Templating in .NET is Still, at the end of the day, a hackneyed, componentized form of include() on each page in different sections of the GUI. And, of course, you can use VS.NET to view your gui, but nthing else. asp: tags. just aren't the same as html.
  
  Anyway, sorry for hte rant. I'm a true fan of Tapestry. I can only say that I wouldn't undertake a google-style application with Tapestry. It does run, like .NET does, a little slower than say a raw cgi/servlet application.
  
  Josh
• Tapestry and JSF
  2003-07-24 11:20:50  anonymous2 [Reply | View]
  
  
  I agree w/ you whole heartedly. I wish the people at Sun and the JCP vendors would have the balls to own up and say "We have fucked up and we are sorry and we will turn to the developer community (not vendors) to help us unfuck ourselves."
• Tapestry and JSF
  2003-07-25 20:13:41  anonymous2 [Reply | View]
  
  
  They need to declare JSPs deprecated and step back from this silly need to standardize everything.
  
  Jason Carreira