On Apr 7, 2005 12:13 AM, Martin Cooper <[EMAIL PROTECTED]> wrote: > I'm not sure what you're proposing here. If you're looking for > feedback on something that might become a Struts extension, for > example as part of the Struts SourceForge project, then I would say > knock yourself out. ;-) However, if you're proposing this as a future > Struts subproject here at the ASF, then I would be against it, for the > following reasons: > > 1) Ajax is just the latest buzzword for something people have been > doing with browser based applications for years. It's just a subset of > the possible schemes that people use for partial page rendering. By > adopting something like this as a Struts subproject, it gives the > appearance that Struts is endorsing this one particular approach to > the more general problem. That will carry a lot of weight in the > Struts community, and since I don't believe that this is the "one true > way" (LOTR again ;), that is not something I want to see.
If at some time, we were to add a Struts Ajax subproject, based on a mature codebase with a strong following within the Struts community, I doubt it would carry any more weight than our adding Struts Shale :) > 2) Many people are already using existing libraries to build Ajax-like > applications. I don't believe that Struts should be providing yet > another client-side implementation. If we really want to have an > Ajax-like taglib as part of Struts, then it should be capable of using > whatever client-side library the developer wants, whether that's Dojo, > nWidgets, Burst, f(m) or Zammetti Special. ;-) That's probably a good idea, if the community finds that this is something people need. I think the path Frank is suggesting does have a distinct Struts feel to it. If he did flesh this out, and it did become popular within the Struts community, then we could consider it on the merits of what our community needs, expects, and, most importantly, will support with posts and patches. > 3) This seems to me to be a particularly restrictive implementation of > the Ajax concept. While it might be possible to expand this to cover > all of the possibilities, I suspect that the end result would be > horribly complicated, making it much simpler to go back to just using > the existing onXXX attributes and defining the rest in JavaScript. I hear that, brother. I said the same thing about modules :) But, on the other hand, if someone is willing to dot the i's and cross the t's, such things can be made to work, especially when there are enough eyeballs in play :) -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
