Howard, I agree that JSF is no real threat to Tapestry. Among other reasons, there are no high-level components (so no real huge benefit to be gained right off the bat). And it's not a terribly elegant way to go. I was surprised to see a lot of controller facilities in there. I expect JSF will get used in place of Struts or another framework (or even straight JSPs) for smaller projects.
However, I don't think you should dismiss it as totally irrelevant either. Here's my thinking: 1) The high-level components apparently won't be in the 1.0 spec. But they'll be in future ones I'm sure. And it really doesn't matter, because every vendor (and several open-source projects) are likely to build them long before the JSF committee does. In other words, JSF should soon offer a mechanism for doing high-level components, and that will give the JSF "framework" (it sort of is one) some appeal as a time-saver. 2) Regardless of whether Sun should have created a Tapestry-like framework from the start, they didn't. Now they have a lot of legacy code to handle, and they're not really free to scrap it all and make the leap it would take to get into Tapestry's league. JSF adds a lot to JSP: browser-independent (smart) rendering, a standard validation framework with both client-side and server-side facilities (even though the range of available validations is now woefully inadequate), stateful components with a tie between the presentation and model, a (very) lightweight (limited) MVC framework, etc. It's a step forward for JSP, even if not an elegant one. 3) It provides the RAD tool vendors with a standard way to support JSP developers. I'm hearing a lot of Java Web developers expressing concern because Visual Studio.NET offers RAD Web development, and while Java developers don't want to move to .NET, poorly informed managers and clients are buying the "time to market" argument Microsoft is pitching (whether or not it is truthful). JSF arms Borland, IBM, Macromedia, and the like with a way to provide RAD JSP development (at least for low-end Web sites). Of course, as JSF develops, it will be essential for Tapestry to make sure it has a comparable set of components. That's not a problem now at all, but I do think the high-level JSF components are coming. Pete Cassetta [EMAIL PROTECTED] > Finally! Sun is opening up about what JSF is. > > My initial impression is: It is no threat. Sun can never admit that = > it's made a mistake, and keeps layering kludges and hacks on earlier = > kludges and hacks in an attempt to set things right. > > I've downloaded the early access release and am working through the docs = > and examples. If anything, they seem to have cribbed some ideas from = > Tapestry (at least, some of the more obvious ideas) ... for example, = > I've seen that they have a ResponseWriter class that has additional = > semantics for elements and attributes, just like Tapestry's = > IMarkupWriter. Probably just folks coming up with the same solution = > independantly. > > The FacesContext is very similar to a merge of IRequestCycle and = > RequestContext. > > Based on what I'm seeing, JSF needs to construct a "component tree" = > dynamically for each request; big questions are: can it handle loops = > inside of forms the way Tapestry can? Part of this is based on the user = > creating a "compound" component id (i.e., "/login-form/user-name-field") = > ... the kind of thing Tapestry does automatically, to any depth ... my = > best guess is that the developer is responsible for doling out uinque = > component ids if loops are employed. > > I suspect that this "tree building" is fairly equivalent to the rewind = > phase used by the action service (and when rewinding forms using the = > direct service). > > The server side interview talked about avoiding session bloat but had no = > specifics. Tapestry avoids session bloat by storing just the persistent = > properties of pages in the HttpSession ... and those tend to be few and = > far between. It also has good facilities for storing objects in hidden = > form fields or encoded into URLs. > > There is a kind of image component that requires a URL ... I don't think = > that JSF handles Tapestry's concept of assets, especially private assets = > (one of the key concepts for easily distributable reusable components). > > Of course, you have typical JSP tag cruft all over your JSP. Hideously = > ugly ... hard to follow, gives me a headache. > > Basically, take everything you don't like about Struts and bump the = > complexity up a few levels. Thank you, Sun. > > Obviously, nothing like the Inspector. Didn't see an (easy) way for a = > component to have its own template ... it seems to be based on a more = > Swing like model, where components delegate to some kind of "RenderKit" = > which means that skinning is easy but getting anything real accomplished = > is hard. > > Their best demo, "cardemo.war", is pretty underwhelming. Ugly, awkward. = > I tried to enter my Zip code "02474", it got converted to 2474 and was = > rejected as being "Under 10,000". Certainly, nothing as cool as = > ValidField going there. > > I had worried that Sun would create something not good, but good enough. = > I'm no longer worried. Tapestry is literally light years beyond JSF = > ... and works with much older JVMs and servlet APIs to boot. > > Well, it 1am here and I should catch some sleep. More tomorrow. I'll = > be posting something a little less rabid to the server side as well. ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
