Forum OpenACS Q&A: Re: ajaxhelper and its tests

jim,

the test cases of the automated tests in OpenACS are are defined with aa_register_case, which defines finally procs with funny names like _${package_name}__$case. These test cases are picked up during the load of a package and they are therefore part of the blueprint and part of the function set of the interpreters in every connection thread (which is memory-wise not the best). Type in a ds/shell e.g. "info commands ::_acs-tcl__*" and you will see the loaded test-cases for acs-tcl. The test cases must reside in the $package/tcl/ directory to be picked up by package loading.

Ajaxhelper does not have such test-cases defined, therefore no such test-cases are shown by automated testing. I am not sure, what kind of tests were intended in ajaxhelper/www/tests/, but that looks like unfinished work to me.

ajaxhelper was developed before the various CDNs (like googleapis.com, or yahoo cdn) became available. We have certainly not the necessary resources to keep copies of the most popular javascript frameworks in various versions around, or to test the effects of every new release on our packages. All large sites i know of design their templates by themselves and main in this process copies of the .js frameworks of their choice on their own. Therefore, the future of the ajaxhelper package is not clear to me.

In my opinion, current client side javascript environments are something too complex and hardboiling to be encapsulated in a package that would fit the needs of everybody.

Of course we could opt for including some of the less intrusive ones into specific UI features in OpenACS. I refer to "light" frameworks as JQuery or such.

However we choose, I fear this "marriage" could abruptly be broken on the next change of direction for web technologies, and would of course mean more work from the community to keep pace with framework development. A real example of this is Ajax Filestorage, build on ExtJS 2 if I recall correctly, and now quite useless, until someone finds time and will to rework it.

From a platform point of view I think we should focus on server side, either by producing plain text, markups/XML or JSON from data, as OpenACS is really good at it and leave fancy client side tecnology to the taste and needs of the single.

Antonio

Hi Jim,

You asked:

"Do you, or does anyone, have recommendations on how to use ajax currently (if not thru the use of ajaxhelper)?"

Just wanted to point out that ajaxhelper includes some useful icons; That's the only way I use it.

The icons comply with the GPL license --a task that may otherwise be tedious to verify individually.

Some icons use reasonably standardized imagery for UI --and is a larger set than available at: acs-subsite/resources

core.js is referred to in www/blank-master.tcl

packages/openacs-default-theme/lib/plain-master.adp refers to blank-master

Antonio,

If I can boil down what you're saying, it's that trying to be as general as possible isn't really possible, or at least it's the typical thing of generalities having diminishing returns.

Fair enough.

So then my (opinion eliciting) question to you becomes, do you think ajaxhelper should just go away? Or, what uses do you see it applied to?

-Jim

PS to anyone, could you post something about its original purpose?

I don't know that it would be worthwhile to factor out the icons. One could generate similar ones if the package wasn't available --just using them to minimize time to produce packages by using existing resources.