IMHO a framework should provide the core functionality that most people will need. Examples are session handling, parsing post and so on. I just believe that there are many things like processing multipart form submissions that have not been properly addressed. I think that file upload, automatic state, rich calendar, collection paging are among the many such commonly used items (for lack of a better term) that should come standard in the JSP spec.
I use Java most of the time and I dabble in .NET, and I can tell you that I can build .NET web apps so fast as compared to JSP that it would make your head spin! Now that I over time have assembled and built my own little framework of components, I can produce in JSP/Java fairly quickly. But this was only after leveraging work from many projects. ASP.net people don't have that problem. Java will be fine and is not going anywhere, but I have to really think twice when am I about to choose a platform now; Java hodge-podge vs. consolidated framework that is ASP.net? The days are now gone with the M$ DLL hell and all that jazz, for those of you out there who haven't really used .NET it is in many ways IMHO J2ee with all the lose ends nicely tied up. :) My 2 cents. Please no flames, I'm just a poor little geek! :) Stefan ----- Original Message ----- From: "Donald Ball" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, November 07, 2002 1:06 PM Subject: Re: Tag for uploading [OT, I realize, my last word on the subject] >>>Jason's classes aren't free software, they're encumbered by a "buy lots >of >>>copies of my book" license. >>> >>> >These days does one really need a lawyer to define *free*. You can >download the code and look at it, compile it and distribute it in your >project if you're non-commercial. Obviously there are no restrictions on >building a decent package with similar capabilities if your working on a >Commercial project. Besides, if you work for a *Commercial Institution*, >I'm sure they'd be glad to buy you one stupid little book so you can >meet the licensing requirements. For a private commercial entity, maybe >that's better than having to release all your code to the world to meet >the requirements of a GNU license. Really, how *one* decides to package >and publish their code is really their business. Nobody said *Open >source* was the *only* way you can go when it comes to exposing the code >of your software. 1. Jason's license requires every member of the development team to own a copy of the latest version of his book. Expense aside, that's a lot of dead trees and a very silly license. 2. Free does not necessarily imply GPL. Most of us in the Apache software community tend towards BSD-type licenses. >I agree that if one wants to see a particular change one can get >involved. That's the power of "Community". But, I think its right that >this would clutter up an already well-defined "spec". It seems a stable >and well organized set of requirements for managing "basic >webapplication request/response" transactions. I mean, good packages do >"one thing" and do that "one thing" very well. Would you agree that the cookie handling code is cluttering up the spec? After all, you can manually parse and generate your own cookie header string. Conversely, would you agree that the servlet API would be incomplete if servlet containers weren't required to parse POST requests for you? You can manually parse the POST requests yourself, but there is considerable benefit to be realized by centralizing that code. I think the same argument applies for parsing multipart/form-data request bodies. >Plus, its sounds like you are trying to change a standard because >everything you wanted wasn't "spoon fed" to you, or because you don't >want to get off your butt and learn to tie together a set of already >existing, community developed, tools that each do their job very well. >Isn't this that "Community Process" that Microsloth CEO Steve Balmer was >ranting was the "Open Source Enemy" several months ago, and then turned >on his coat tails and started crying, "We need to embrace the >Community!" The whole point of community is that no *one* entity has the >monopoly on the code! No one entity defines all the standards! It's this >diversity that makes for the ultimate flexibility and ultimate >interoperability. By not restricting the file upload functionality into >an API, it leaves it open for competitive open source development (In >reality, I just wish JCP had done the same for the HttpSession API). ??? The API just defines an interface which programmers who want to develop portable applications can use. The implementations of the interface can compete, proprietary, open source, what have you. And still, people who don't like the API can develop their own superior API (SAX, anyone?) and use that. Nothing forces you to use the session API; you're free to write your own and use it if you like. Anyway, I guess I still fail to see why adding support for multipart/form-data requests to the servlet API is controversial, and I encourage people to write the servlet JCP. Back to taglibs now. - donald -- To unsubscribe, e-mail: <mailto:taglibs-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:taglibs-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:taglibs-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:taglibs-user-help@;jakarta.apache.org>
