+1 Frank! Good old agility and Xtreme principles say do it and worry about all this "wah wah wah wah" later. You have a simple and very useful idea which is at the beginning stages but which is well-thought out and which is based on a solid engineering foundation. Go for it as you initially conceived it.
Jack On 4/19/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > 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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
