Forum OpenACS Q&A: 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.

Thank you for that suggestion, Gustaf.

I hadn't thought through how to handle changes with the dependency of openacs-default-theme/lib/plain-master on www/blank-master

Of course, one can copy blank-master to a custom themed package and modify it there. To help track changes in blank-master versions, keep a local unchanged copy of blank-master in the theme to diff against openacs revisions.

In the same script blank-master.tcl we have xinha and tinymce inclusion, plus other miscellaneous stuff which would fall under the same case of bad practice.

I'd say the same replacement I've suggested should be ok, but I cannot seriously test every possible difference.

I can go for it anyway, but this change should be audited by people using editor on their sites (I don't)

Committed change for core.js and warned for remaining cases in blank-master.

All the best

Antonio

hmm, i am not sure, whether the inclusion of core.js on every html page this is the best solution. Including core.js in every page means to increase the size of every page by 50 KB. On our production site, we have up to 4mio page views per day, that would mean to increase the traffic by 200 GB per day, if i have not messed up the zeros.

The better approach is to cache the core.js with a high expire time, or to use async loading.

The more important issue is, whether we really need all of core.js on every page. The largest part of it is the calendar widget, which should be only included in pages that need this.

The "old bad way" was that with a stock OpenACS, the js was loaded as an extra resource, the "modified bad way" is that it is now increasing the size of every html page by 50 KB. Assuming that the average HTML size is about 50KB [1], the literal inclusion (the new way) doubles the size. This is especially bad for mobile devices. When setting expire time high on this static resource (as recommended by the usual guidelines), the old way did not require a retransmit at all.

I would appreciate much more if someone separates out the various pieces of core.js for different usage scenarios, and includes the stuff were needed over including the whole mess on every page.

-g

[1] http://www.sitepoint.com/average-page-weight-increases-15-2014/

Sorry, but I don't understand: checking network usage from Chromium on my installation, now that core.js is in body, I see that response from server is "304 not modified", so caching is taking place into browser and no extra traffic is generated.

The same happens reverting to the previous way of including: js is loaded only the first time and then taken from cache.

Why should page size increase?

I'm having a look, but I need opinion on this:
I think we should change template::add_body_script code so it checks for duplicate inclusion of the same script as template::head::add_script does.

The need for this comes from this consideration: to keep js inclusion the closest possible to the tcl actually requiring that, I would put acs_RichText_* inclusion into template::widget::richtext_or_file proc. This proc can be called multiple times for each widget, so it would be convenient if we had a mean to avoid multiple inclusion in body.

As multiple inclusion of the same script in body could make sense (multiple execution of the same code) this should be parametric. I was thinking about the following:

- if the flag 'once_p' is given, behave like template::head::add_script and update reference into script array
- if flag is not given, put script into the 'anonymous' special element of array so no check is performed
- change template::head::prepare_multirows so it knows that now body_scripts is an array, rather that a plain list

What do you think about that?

I would just ask... is the reason for this change simply to include the javascript elsewhere (body instead of head)?

I think it's a good idea to check for dups. In fact, thought should be placed on whether there should be two separate namespaces (one for body, one for head) or one namespace for both -- do we want to deny a dup that originated in the head whose destination is body, or vise versa?

-Jim

FWIW, aforementioned templating system checks and combines scripts in terms of their purpose/usage i.e. whether a page is for registered users or the public. It also separates the scripts between those that can be deferred and those that are not [see slide 15 in the aforementioned EuroTCL presentation]. This is accomplished by tagging a JS code snippet with the relevant word, e.g. "public", "private", "defer", "nodefer" [templating system generates the files automatically]. Similarly, one could generate scripts for different browsers, language codes, and so forth.

Hi Antonio, I would very much like to do that (re: tutorial) though later in the summer as I'm somewhat swamped with a number of different things these days. That said, I would be glad to contribute in the development of the existing templating system or even integrating the two systems if the community finds that to be constructive. Overall, I'm all for contributing more in open-source projects, and OpenACS in particular, including bringing the work I've been doing over the years to converge with the existing codebase. Not sure what the best way is just yet. Just letting everyone know that I'm willing and, hopefully, perceived to be able to get the job done.