These are all pretty much easy to do for any specific application. The problem is doing it in such a way that you can plug in L&F. Ideally, you should be able to do this using an app-specific stylesheet and a component that emits the correct "class" attributes in the correct places. This is what the Palette component, for example, is *supposed* to do ... it needs more work to look right on browsers besides IE, however.
----- Original Message ----- From: "Vladimir Ch." <[EMAIL PROTECTED]> To: "Howard M. Lewis Ship" <[EMAIL PROTECTED]> Sent: Tuesday, September 03, 2002 3:38 AM Subject: Re: [Tapestry-developer] Re: JSF > > IMHO > Calendar, TabPane components too... > > ----- Original Message ----- > From: "Howard M. Lewis Ship" <[EMAIL PROTECTED]> > To: "Pete Cassetta" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Tuesday, October 01, 2002 2:21 AM > Subject: Re: [Tapestry-developer] Re: JSF > > > > 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 > > > > ------------------------------------------------------- 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
