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:
I wasn't proposing anything more than getting feedback, see if there was any interest in this. I figured I had done enough to get the general idea across and I didn't see any sense in putting in the rest of the effort if no one was going to support it. If there was support, my feeling was that it would just be a new version of the HTML taglib, perhaps released in concert with Struts 1.3, perhaps not. Ted mentioned the idea of a new subproject, which I wasn't against, but it wasn't what I was thinking when I first posted.
1) Ajax is just the latest buzzword for something people have been
doing with browser based applications for years.
You and I know that (we've had some exchanges in the past, I know you do many of the more complex client apps like I do), but many people are just coming to the realization that you don't have to refresh entire pages all the time, and whether it's a new buzzword for something old or not (it is!), it does seem to be something new to a lot of people, and there is growing interest in such techniques.
> 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.
That's a valid point. No doubt there are 100 ways to skin this particular cat, and I wouldn't even claim to be proposing the best of the bunch.
But then again, knowing what you know about more complex client-side development, wouldn't it perhaps be helpful to people wanting to do things like this to have some degree of this type of functionality built in to the tags they already know and use?
Mind you, I'm all for walking with you or anyone else that is interested right in to Mt. Doom and trying to forge that One True Way :) If its something completely different than this, so be it, but I'd have to be convinced, just like anyone else :)
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. ;-)
But aren't those people already away from using Struts tags? I admit I am not familiar with the four libraries (and the one you posit :) ), but I would assume you don't use Struts tags with them (at least not the HTML tags). If that is the case, I don't see why that would clash with the idea of having some Ajax-type capabilities in what you could view as the more "generic" Struts HTML tags at that point.
For those people who are still using the Struts tags, and I'd bet most of them are building more "classical" web applications, why not open things up for them a bit? For those using more robust libraries, no problem, just ignore the HTML tags, as I'm betting they do already.
It's kind of like saying people shouldn't have access to a Ford because there are Lamborghini, Jaguars and Lexuses out there. Some don't need or want a Jaguar, but it's nice that they can get a Ford that suits them. I'm proposing providing the Ford :)
3) This seems to me to be a particularly restrictive implementation of
the Ajax concept.
I'd be interested to know in what way you see restrictions... Perhaps they are things that could be addressed...
> 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.
Hibernate is way too complicated. Doesn't stop anyone from using it. EJBs are far too complex. Many use them. JSF is quite complex, many people have no aversion to it. I don't think this would be even as complex as the simplest of that bunch :)
Not that I'm saying complexity isn't to be avoided. It almost always is in my mind. And I would agree, for anyone with the knowledge and capability to do something like this themselves, they frankly probably should as you point out.
Well, I asked for feedback and that's what I got :) You have a huge say in how things go Martin, so if this doesn't fit your vision then I suppose it's dead in the water.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
