On Tue, April 19, 2005 2:47 am, Craig McClanahan said: > This is exactly the area I've been having trouble with this proposal > as well ... tell me again why you can't use Ajax techniques with the > standard Struts HTML tags?
No one, at least not me, has made that statement at any point. I frankly do not use the Struts tags most of the time, yet I do AJAX just fine. There is no debate on this point: there is no NEED for the Struts HTML tags to do AJAX. > If you can do it with handwritten HTML > pages (which you certainly can), you can also do it with existing > Struts HTML tags (or the standard JSF components, for that matter) > that offer attributes like "onchange" and "onclick" to plug in your > calls to JavaScript methods that do the actual background calls, and > then update the client side DOM of your page. Agreed. But then you have to do everything yourself. If 80% of the time people are doing the same kinds of things like replacing the content of a specific DOM elements' innerHTML, why not provide a standard approach to that? Further, we are constantly talking about the dichotomy of having a separate group of "page developers" and "back-end developers". Why should a page developer need to know Javascript? Isn't that like saying they need to know Java on the server? You could of course make the argument that scripting is appropriately a part of a page developers' reportoire, and I don't think I would argue, but they already avoid a great deal of scripting by using various taglibs, so why shouldn't they want to avoid scripting to implement at least basic AJAX techniques? That is what is at the heart of what I did. > It seems to me that a framework can provide value add in primarily the > following areas: See, when we start talking about a "framework" we are starting to talk about something more grandiose than what I put together. That is in no way to say it isn't a good idea, just that it is different. > * Provide a client side JavaScript library that does the grunt work > of making the back-end XmlHttpRequest call, and updating the > corresponding portion of your DOM. Martin likes DOJO for this; > there are also a bunch of other libraries that do the same sort > of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. It is amazing to me that anyone would make the argument against something that is too simple! Why do we always have to develop the "next big thing" rather than something that will help 80% of the people 80% of the time? Why is the later a seemingly Bad Thing? > * Provide a server side framework that makes it easy to map > a particular XHR invocation to the corresponding business logic, > and (for extra credit) maps the response data to a generic data > format so you don't have to write specific formatting logic for > every single response type. I sort of like what JSON provides as a > transport protocol, but there's room for value add here on the > server side, with a generic data abstraction that maps into > the appropriate transport formats. I do actually like this idea, but again, the difference between this and what I put together is night and day... this is leading down a much more complex and expansive path. It's a path I would be excited to walk down, but it puts delivered results further away as opposed to what I did that could be completed in relatively short order and help people NOW. Also, what you are talking about, and what Martin has been talking about, while a good idea to be sure, doesn't really help people with existing apps. It is akin to my Struts Web Services project... I have never at any time promoted that as the be-all and end-all of Web Services. What I have said is that if you have an existing Strtus-based application and need to expose parts of it as Web Services, here's one quick and easy way to do it. Likewise, what I proposed is a quick and easy way to introduce AJAX functionality into an existing app with a minimum of fuss and muss. There is not a lot of code to write (none if I do it right) and it's not an all-or-nothing proposition, you don't have to use a whole new framework on the client and the server to make it work. The what you and Martin are talking about, I can't see how that would be the case. So, while the ideas may have a great deal of merit, they require a far greater change for developers and don't, I think, help anyone NOW. > * Provide encapsulated functionality (JSP custom tags, JSF component > tags, whatever) that totally hides the fact that Ajax techniques are > used > into the HTML and JavaScript markup that is automatically generated. > If you make the page developer have to do a *lot* more (i.e. a bunch of > nested tags) on every Ajax-sensitive component, that doesn't seem to > make application development easier ... it only makes it more tedious. Granted. My proposal very much fits those goals. A page developer has only to add a single new attribute to a tag they want to AJAX-enable, and write a corrsponding entry in an XML config file for it. Done. NO code whatsoever has to be written, aside from whatever they want to do on the server, which may be nothing too. > Use case to consider -- as an application developer, I want to use a > progress bar "widget" that periodically polls the server for the > progress of a long running function, and then updates the client side > visual representation. If I have to do more than add a single > attribute (some way to map to the server side function that returns > the completion percentage to be displayed), plus an optional parameter > that says how often to check, over what it takes to specify a static > image with an <html:img> tag (for example), then I'm likely to say > "thanks but no thanks" to your version of that widget. This is where there seems to be some understanding that needs to occur... I am in no way shape or form proposing an entire new widget set. I have thought about that, have done some preliminary work, but that has absolutely zero to do with my proposal and what I put together to demonstrate it. I am NOT talking about creating a new JSF here Craig. I am not talking about something that grandiose. There is no such thing as a progressBar element in the HTML taglibs with which I am familiar. All I am talking about is adding the ability for client-side events that fire for the HTML tags that EXIST TODAY to fire server-side functionality and do one of a number of standard things upon return to the client, as well as allow a developer to easily implement their own actions (i.e., if you look at my example, you can specify a standard return action to perform, or you can simply specific the name of a Javascript function, at which point you do whatever you want). > If, on the other hand, you let me say: > > <html:progressBar progressURL="/filecopy.do"/> > > or > > <html:progressBar progressURL="/filecopy.do" interval="3"/> > > then I'm fat, dumb, and happy. Why should *i* (the application > developer) care that you're using XmlHttpRequest behind the scenes? Then you would be fat, dumb and happy with my proposal I should think! All the developer has to care about is (a) what is the form of the data submitted to the server, if there is any, (b) what happens on the server when such a request is received and (c) what happens when the response comes back. In short, the page developer worries about very little more than they do today, and back-end developer still has all the same responsibilities, and no one has to use a whole new widget set or learn a whole new taglib to do this all. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
