On Mon, December 5, 2005 12:11 pm, Pilgrim, Peter said: > Right, If I understand what Frank is saying then this is a HTTP Servlet > that just parsing the input request, which is XML and generates > a response which is also XML.
To my understanding, that's precisely what DWR is. DWR is a form of remoting, as the name says, which is one interesting usage of AJAX, but by no means the only one. > As some one also working in the ``banking environment'' <snip> Me too :) > So basically if you architectured your application correct, and > pushed all or most of the logic to the business delegates or facades > then it should be easier to add AJAX server side. Yes, and it should relieve you from having your AJAX code tied to a specific framework in the sense that the real work is being passed along from the "framework" code to what is actually doing the work... wow, that was convoluted! All I really mean is that if you have a POJO MyAjaxHandler class, you can call on that from a Struts Action or a JSF backing bean or a plain servlet or whatever else, your AJAX code doesn't depend on the framework your using. > Essentially to do the Google suggest thing for my perspective > is that you have cache on distincts e.g > ``SELECT DISTINCT(CONTACT_NAME) FROM EXTERNAL_REFERENCES''. > You store the results in a sortable collections for a user session > or ORM cache. Do this for all the input fields for your input > forms that want to add the suggest feature > The AJAX server method just filters on the string input > from the html text fields and returns the XML result set > of possible matches. Pretty much, that's it. Incidentally, I have this exact thing in the cookbook for Java Web Parts: http://sourceforge.net/project/showfiles.php?group_id=140728&package_id=167877 Admittedly, I haven't made this as easy to find as I should, and it's not a true "cookbook", it's really just a collection of examples at this point. But, it includes a Google Suggests rip-off that you should be able to just drop in your container and play with. It's just using some hardcoded data, no database or anything, but the essential concept is there. > I thinking of implementing the Google suggest concept for > my client for a ``big form''. Is your subproject up to it? AjaxTags is actually one of the more mature pieces of Java Web Parts, and I know a number of people using it in production with great success, so I'd say yes :) However, it's only fair to point out that what AjaxTags offers you isn't a complete solution like some other AJAX toolkits... there are toolkits that give you that Google Suggests feature out-of-the-box, and that is appealing to many. AjaxTags will make it very easy to build this yourself, but you in fact will have to code the server-side of it. I personally prefer it this way, but YMMV. Take a look at the cookbook example and see how simple it really is, then see what the other toolkits offer and make your decision from there, that's my advice :) I should also point out that there is a whole project named AjaxTags at SourceForge, not affiliated with AjaxTags in Java Web Parts, which in fact *does* offer a ready-to-use Google Suggests implementation. > Does your current version handle simple or complex XML documents? > Should I wait for you release? Well, the short answer is both, but I think the longer answer is in order :) To properly answer that I have to describe what AjaxTags is, and probably the best way to do that is a simple example. But first, some exposition... With AjaxTags, you can attach an AJAX event to a given page element, whether they are part of a form or not, and define handlers for the request and the response. Let's say we have an HTML form like so: <form name="form1"> <input type="text" name="acctNum" /> <input type="button" value="Click Me For AJAX" /> </form> <div id="results" /> Let's say what we want to happen is that when the button is clicked, we want to take all the values in the form it belongs to, construct a simple XML document from it, send it to the server, and get back some content to be inserted into the <div> right below the form. This is trivially easy with AjaxTags. What it will require is: (a) Adding two custom tags to your page... one is the <ajax:enable/> tag, which has no attributes, and comes at the end of your page. Pretty much just a set-it-and-forget-it thing. The other is the <ajax:event/> tag, which comes directly after the button you want to enable. So, on the above page you'd do: <input type="button" value="Click Me For AJAX"><ajax:event ajaxRef="form1/button1"/> The ajaxRef ties this AJAX event to the config file, which comes next... (b) You create an ajax-config.xml file where you define what should happen when various events occur. For this example, it might look something like this: <ajaxConfig> <form ajaxRef="form1"> <element ajaxRef="button1"> <event type="onclick"> <requestHandler type="std:SimpleXML"> <target>example1.do</target> <parameter>searchParams,acctNumEntered=acctNum</parameter> </requestHandler> <responseHandler type="std:InnerHTML"> <parameter>results</parameter> </responseHandler> </event> </element> </form> </ajaxConfig> What this is saying is that when button1 on form1 is clicked, we want to use the standard (i.e., included with AjaxTags) handler named SimpleXML. This handler looks at the parameter string and constructs XML based on it. So in this case it's saying that we want to have an element in the XML document named acctNumEntered, which takes its value from the element of form1 named acctNum, and the root element of the document should be searchParams. So: <searchParams> <acctNumEntered>???</acctNumEntered> <searchParams> ...where ??? is of course what the user entered, is what will be sent to the server. Notice that you haven't written any code at all here :) This XML will then be sent to the URL example1.do, which presumably in this case is a Struts Action. Now, what happens at this point is 100% up to you, AjaxTags has nothing to say about it. There are a number of standard request and response handlers, but one of the neatest things about AjaxTags is that you can define your own handlers to do more advanced things. If you wanted to constuct a far more complex XML document, you could write your own request handler to do so. In fact, the now standard XSLT response handler was contributed by a user who originally wrote it as a custom handler. That one uses Sarissa to transform XML returned from the server via XSLT. That's considerably more complex than most of the standard handlers, and serves as a great example of the flexibility offered. So, hopefully it makes sense now... the short answer: out-of-the-box AjaxTags handles simple XML documents, at least being transmitted from the server... none of the handlers will understand XML coming back from the server at this point. The long answer: it's easy to write your own handlers to do just that! :) > When I surf there a week ago they did not have any real life > example and I have just gone there now, ... and they still dont > have real examples. I think this is because it is still V0.1 > and requires knowledge of JavaScript. You can play with the > unit tests http://archive.dojotoolkit.org/nightly/tests/ and > the rich text editor http://dojotoolkit.org/docs/rich_text.html > work nicely on the standard Internet Explorer here. I agree, I've had a bit of trouble getting my brain wrapper around Dojo as a result of a lack of examples and extensive documentation, but that is I think because it's still early in its life as you say. What I *have* been able to figure out looks very promising though, and there's certainly been a number of highly impressive examples pointed to (the Mac launcher widget was *extremely* impressive for example). Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
