> ".Net severly constrains the objects that can be present "on the page" in > terms of their own, specific APIs for database access, etc."
And where did you get that from?? .NET components will bind to any "data source" using a well defined interface - and that will be made more flexible in 2.0 Things I'd like to see addressed: - Button listeners firing after the form is posted - this one is a cause of a lot of grief. If Tapestry's philosophy is simple, then this should be addressed. I find myself playing tricks just so I can deal with this. - A .NET like client side state persistence will enable more events - such as valueChanged for a text field. This is again something you've got to put hidden fields in Tapestry to achieve ----- Original Message ----- From: "Howard Lewis Ship" <[EMAIL PROTECTED]> To: "Tapestry users" <[email protected]> Sent: Friday, May 06, 2005 2:53 PM Subject: Re: As a User, which two items would you personally most like to see in the next Tapestry Release? > > > I want the OOB component set to rewind perfectly every time with no > intervention on my part, no third party libraries, and no massaging of my > forms to worry about things like order of operations and/or changing > something during the rewind cycle. .Net severly constrains the objects that can be present "on the page" in terms of their own, specific APIs for database access, etc. That won't fly in the Java world ... Tapestry needs to stay compatibly with JDO/EJB/Hibernate/Castor/Ad-hoc/raw JDBC. Flexibilty can be a curse. MindBridge's For component rolls together Foreach and ListEdit nicely, but still needs some configuration to figure out which object property is stored into the form, and how to convert it back to an object during the form submission. If you look at the pace of changes recently, you might just pick up on how important HiveMind is to Tapestry 4.0. Here's a few cool things I've been able to add, largely because of HiveMInd: - A plethora of binding prefixs (supplmenting "ognl:" and "message:") that simplify templates and offer much better performance (no reflection) - Much smarter component parameters that just work without having to figure out the right "direction" - Persisent properties stored on the client as query parameters and hidden fields - Improved line-precise exception reporting that displays the actual source - Native JSR-168 Portlet support, as an add-on library - Native, configrable friendly URLs without a seperate patch - Elimination of trivial .page files - Modular applications (spread across multiple folders) ... and much more that slips my mind. Most of these were driven by my own needs (as a Tapestry user, not as a Tapestry developer) and those of the community. I'm the guy at the front of the class room who sees what's tripping people up the worst. The input is valuable, and 4.0 will be a significantly better platform to develop applications and reusable components on. It's all a matter of prioritization. The HiveMind work, and the improved test suite, lets me move faster and faster and make more and more aggressive changes. -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
