I need to check the validation subsystem to see how easy it will be to implement client-side checking (as well as server-side).
I think we all agree that Tapestry (even Tapestry 2.1) is a stronger base for building components. More high-level components would be very good, yes. Especially, integrating them into the live demo (the Workbench). I wouldn't mind a little help there, even on the exiting Palette (which needs a touch of work to be truly cross-browser). Some ideas: Grid -- a Foreach that renders its contents in a grid, with control over the number of rows and columns. DateInput -- many variations, preferable including one with a pop-up calendar window. Browser -- generic version of a paging browser with customizable L&F and control over sorting. TreeView -- some kind of tree-oriented widget for navigating hiearchies of objects. And documentation ... the revamped tutorial that is beginning to crank up, and the Tapestry Book which I should be working on right now (instead, I've been tying up the loose threads of 2.2-beta-1). ----- Original Message ----- From: "Pete Cassetta" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 30, 2002 3:17 PM Subject: [Tapestry-developer] Re: JSF > 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 ------------------------------------------------------- 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
