-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to thank you for your comments. I don't view those who "bash unabashedly" (on this list or any other) as anyone to listen too closely to. Your comments on the other hand are superb.
I've been working with (in/around/through) Tapestry for quite a while doing things that would have turned my stomach using JSP's and I don't find too much of an issue with anything you said (notice I added "around" to my "working with" experience) so I'll just respond inline to your specific points. [EMAIL PROTECTED] wrote: > Not to open an old wound.....but Tapestry's mantra is "static components, > dynamic behavior", and that seems very crippling to me from an enterprise > development level. You don't have to go far in enterprise development to > need dynamic components. Yes, I know, Tapestry can do dynamic components, > but it's not a natural process and it is poorly--very poorly--documented. > > Someone commented to me that they thought Tapestry had an infinite > learning curve. I disagreed. I said, it has a steep learning curve, but > then it levels off. If you stay on the narrow beaten path, you can > sprint. But if you deviate, your sprint frequently encounters wall after > wall (e.g., application catalogs in 3.x). In an enterprise environment, > the walls appear pretty quickly. Those walls would disappear, or at least > become speed bumps, if these problems were addressed: > > Dynamic Components Agreed - on the surface. The problem with "Dynamic Components" is "what do you mean?" You have your ideas, I have mine - make it so both of those cases work and someone else will ask "Why doesn't it handle dynamic components?" I do believe there's a baseline that isn't conducive to Tapestry development that I hope will change (without "Block"ing it), but until then other issues slow down development more than this (at any level: basic or 'non-basic'). > Documentation / Quantity and variety of Books AGREED. And working on it. I can't recommend Kent's book enough after using it myself to get a customer's confidence in the "ease" with which they could maintain their system (wasn't exactly a simple site). But I'm also a believer that OSS in general lacks good/useful user documentation. Check around on archives and it's a theme of mine. And that's where my "working on it" comes in. I don't believe any user should have to buy a book to be able to develop an app. Books should be for "beginner to intermediate to advanced" progression, not "here's how you start". How do we get there? Start writing. Problem is that most developers don't like to write anything but code (and e-mails ;-) ). Hopefully we can move forward with a better handle on this. > Advanced Examples I lump this in with documentation so I'll lay off a lengthy reply to this one > Backwards Compatibility / Kind Migration Path Two completely separate issues - both with their own intricacies. There comes a point where it doesn't make sense to continue to support older releases. At present, 3.X isn't in that category. There are things that are easier in 4.X, but that doesn't help a 3.X install base that can't/won't upgrade. Migration path - agreed. Sometimes you have to spell out how to do things, sometimes say it can't be done and other times just sit back and wait to see what users have managed to do with one release that you didn't ever think anyone would want to do and address those individually. A better handle on documentation is also the key to this piece. > Bug Fixes for 3.x *cough* okay... (may have proposed a patch or two on this recently ;-) ) > Better i18n Support This one I might want to question... (read: huh?) I'm not saying it's the best, but Tapestry internationalization is better than most of what I've worked with. If there's an enhancement you want and you haven't already done so, create an issue (please mark it as an enhancement if that's what it is). The developers are all going full-steam in a progressive direction and I'm sure an issue would be easier to track than an e-mail on any list. > > As a result, these larger issues arise: > > No confidence in reuse This is all in who you are and the types of components you have. If you want to create a dynamic block for your page I'm sure you could reuse it all over the place - thereby losing any benefit from any framework, but the devil's in the details. > Few widget libraries of consequence, if any Hmm... Agreed? Disagree? Not sure if I'd agree with "few" - but definitely disparate at best. But yes, they could _always_ be better and more abundant. Catch 22 here for non-developers and non-users (aka: vendor? outside support?) - it won't have them unless it is big enough to be worth it, and it isn't going to be big enough unless it has them. > Lack of talent on the street ... Thinkin' documentation would help a bit here... after that? Change streets? :-) > Lengthy development cycles Agreed. Completely. Let's fix that. > Questionable maintainability This one... I'd have to know what you mean. I feel so much better about maintaining a Tapestry site than anything I've seen with JSP/ASP. If it's an HTML maintenance task a designer can do it. If it's true application maintenance it's usually easier to see how/why things happen than going to a JSP/ASP page and trying to decide if it's in the Servlet, the Action, the JSP/ASP itself. > > Tapestry does a lot of things right, but they tend to be technically > "cool" things. Work days, at least in English, are called "business days" > for reason. And I thought business days were called work days... ;-) > > - Mike Thanks again for your comments. Believe it or not, this kind of specificity does help. Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) iD8DBQFEIfEOaCoPKRow/gARAgafAJwPpz9Iw40n+kNU/DzzUV182Y4q3ACg4OSH Sc5+DfKaxP6BqSaRBN3PsKg= =63Z5 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
