Slashdot Mirror
COWS Ajax - Ajax Evolved
nuttzy writes, "COWS Ajax takes over where Ajax leaves off. The web has gone through a great period of experimentation and there is now a dizzying array of frameworks, add-ons, howtos, and books. The common drawback these Ajax aids all fail to overcome is that, even with aids, apps take a long time to create and debug. Many times someone has already created a great tool and you'd really just rather use theirs instead of reinventing it (especially if it's a Google, Yahoo, or other trusted player). Wouldn't it be great to drop in a single line of code to gain a huge amount of functionality that frees you for something else? You can't do that with Ajax, but you can with COWS (Changeable Origin Web Services) Ajax. Now highly interactive third party services like SpellingCow are possible."
Sounds good. Developers should milk it for all its worth.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
But if a dev in my team would ask this to implement I would ask a few questions:
- Does it work if the embedded page is offline?
- Does it slow down if the embedded page is under heavy load from somebody else?
- Does it break if some standard/lib/implementation/EULA changes?
- Can we customize it to our GUI?
- In the example given, how does it play with browserspellcheckers like the one coming in FF2.0?
- Why are we paying you if all you do is reuse thirdparty code wich doesnt belong to the company?
You get the idea. Not saying its a bad idea but I have my concerns and so would a lot of managers/devs. At least the ones I have the pleasure to work with.
Next time you release an API, don't tell us "Instead of sorting through the techno-babble, let's just say [whatever]." This phrase immediately engages my bullshit sensors. You've apparently got a nice wrapper around the cross-site problems, just say that. Anyone who understands will be interested, anyone who doesn't won't care either way.
there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
You have two cows. They eat AJAX and die.
Karma: Excellent (fuck, even in the future moderation doesn't work!)
From the spell checker:
That's so very AJAX.
It really is asking for trouble, once you have third party javascript on your site you are
basically at the mercy of whoever wrote that javascript.
They can do nice stuff, and not so nice stuff with your end users (popups, form content
hijacking and so on).
And possibly lots of stuff that I have not even thought of. Also, they're pretty much
in control of the timing on your site, some browsers do not display the page until all
java script has loaded and if you are loading it from a remote server then you are
basically as slow as that server.
Yay, buzzwords! Ruby on Rails was fun, and now there's COWS Ajax!
What's next, Python on a Plane???
Wow... a web service based on a cross-site scripting vulnerability.
That's brilliant.
Now third party websites can offer to check my spelling and eavesdrop on my conversations with only one line of code!
I know I'm excited.
-1 Uncomfortable Truth
the echo2 library is an Ajax library which makes web application development as easy as desktop application development; it is an all-Java framework with no need to write even one line of XML/HTML/JSP/other. You can find it here:
http://www.nextapp.com/platform/echo2/echo/
Ouch. Adding a script tag dynamically is old hat in Ajax. See the DOM Based On-Demand Javascript pattern.
n g
In fact, there are a number of project under way that use dynamic script injection to emulate cross-domain XHR. See http://ajaxian.com/archives/jsonp-json-with-paddi
But worse yet, the argument that developing web applications with Ajax is hard is a straw man. Imagine you had to design a desktop GUI by twiddling with the screen bits directly or, worse yet, implementing application logic in the graphics controller. Blech!
That's the situation with Ajax and webapps right now: writing code in the wrong places and at the wrong level of abstraction.
If you want to simplify how you write webapps using Ajax, try a server side framework like Echo2 or ZK. These allow you to write webapps much like a desktop GUI while working in only one language context -- Java on the Server side.
We're looking at the worst kind of "copy and paste coding" here: the kind that can change at any time in the future. If you can't write a spellchecker, and you can't copy one from someplace else, you're going to look mighty stupid when the cow-speller site goes down, and you can't fix it.
Seriously, by doing this, I'm not only trusting this bovine-fixated individual to not only (a) never change his API, (b) always be up, (c) never do evil things with my data, but also (d) actively prevent evil things from being done with my data.
Consider for a moment that you write an email client that "leverages" this technology. In this situation, not only are you handing your logs, you're also potentially passing your customer's email and passwords to this cow-speller.
Bad fucking idea...
Er Galvão Abbott - IT Consultant and Developer
I was actually thinking that one of the 'benefits' of this technique is that you could release a tool for people to use WITHOUT releasing the source (or backend database, or any other tools/data used). This is more of a benefit to the Googles and Yahoos, or the guy that wants to eventually make money off this tool, not the end-developer integrating it.
Overall, it seems to me like a solution to a problem that just doesn't exist. There are already ways to access web services from the server-side (SOAP, XML-RPC, REST, and so on). To make use of these sources with AJAX, you just need to code some AJAX glue to tie it together. Using the toolkits that most languages have now, this can literally be 5 or 10 lines of code.
You also get to control the code that gets returned - set your own timeout (server-side) for fetching data from the web service; not have to worry about the hosting site going down and possibly breaking your app; not worrying about the remote end getting comprimised (since it would be a bright shiny target, and you don't know anything about their security); not worry about them shutting down operations, switching to a pay-per-use model (see above), changing the API in a non-BC way, etc.
Speak before you think
The way you're developing apps has little to do with Ajax, and more with using the correct design... Any half decent application (not just web apps...ANY APPS, aside for very specialized stuff, and even then) should be like that... separating everything so that the front end and the back end (and the data access layer, and the security, and the validation, and...and...and...) are separated, so that you know exactly where any problems are, how to fix them, that fixing them usualy won't break anything else (unless a structural change is made, obviously), and so on.
:)
Its just...the tried, tested and true way of doing thing, ajax or not
Looks like SpellingCow was lifted from another project without attribution (http://me.eae.net/archive/2006/09/04/spellingcow/ ). This whole post/project smells fishy.