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

Collapse
18: Re: ajaxhelper and its tests (response to 17)
Posted by Antonio Pisano on 03/27/15 11:58 AM
Committed change for core.js and warned for remaining cases in blank-master.

All the best

Antonio

Collapse
19: Re: ajaxhelper and its tests (response to 18)
Posted by Benjamin Brink on 03/27/15 03:44 PM
Thank you, Antonio!
Collapse
20: Re: ajaxhelper and its tests (response to 18)
Posted by Gustaf Neumann on 03/27/15 04:39 PM
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.

Collapse
21: Re: ajaxhelper and its tests (response to 20)
Posted by Antonio Pisano on 03/27/15 04:57 PM
Of course we can decide about this too, but just to be clear, core.js was already included before, just in a "bad" way.

As far as I know, core.js is required for templating features as form focus property for adp files and checkbox selection for templating::list.

We should probably revise javascript codebase really essential, move its inclusion at the right place and get rid of the rest. For example, we still ship extjs2, which is very old, and maybe other stuff that doesn't really belong in OpenAcs.

Collapse
22: Re: ajaxhelper and its tests (response to 21)
Posted by Gustaf Neumann on 03/27/15 05:13 PM
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/

Collapse
23: Re: ajaxhelper and its tests (response to 22)
Posted by Benjamin Brink on 03/27/15 05:29 PM
Great idea to separate out the various pieces of core.js to their usage areas.

Perhaps this is a good time to add a parameter with a reasonable default expiration for serving static files. ( https://openacs.org/forums/message-view?message_id=4231891 )

Collapse
24: Re: ajaxhelper and its tests (response to 22)
Posted by Antonio Pisano on 03/27/15 05:43 PM
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?

Collapse
25: Re: ajaxhelper and its tests (response to 24)
Posted by Gustaf Neumann on 03/27/15 08:09 PM
Antonio sorry, i misread. the change is not is not including the core.js literally (i.e. replacing the link by inlining the content, but just moving the definition down to the body. seems that i do too many things at a time.

moving stuff down will work most probably for "widgets" like the calender widget, but not for functions which will be needed earlier.

Many of the functions are not needed at all (imho), the calendar should go into its own file, the acs_List* and acs_KeypressGoto are still needed. It would be appreciated if someone can shed more light on the functions marked with "?"

The move-to-the-body-change might break the focus handling in the blank-master. 

document.getElementById -> ancient stuff, not needed

acs_Focus -> www/blank-master.tcl
acs_FormRefresh -> ?
acs_CopyText -> ?

acs_RichText_* -> packages/acs-templating/tcl/richtext-or-file-procs.tcl
acs_rte* ->  www/blank-compat.tcl
acs_initHtmlArea -> ?

acs_ListFindInput -> packages/assessment/www/asm-admin/session-delete.tcl
acs_ListCheckAll -> packages/acs-templating/tcl/list-procs.tcl
acs_ListBulkActionClick -> packages/acs-templating/tcl/list-procs.tcl
acs_KeypressGoto: packages/acs-templating/resources/forms/confirm-button.adp

Calendar
Collapse
26: Re: ajaxhelper and its tests (response to 25)
Posted by Antonio Pisano on 04/02/15 12:33 PM
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?

Collapse
27: Re: ajaxhelper and its tests (response to 26)
Posted by Neophytos Demetriou on 04/02/15 08:20 PM
I think it's very good idea. In fact, I did something similar in the templating system (http://www.tcl.tk/community/tcl2013/EuroTcl/presentations/EuroTcl2013-Demetriou-WebTemplating.pdf) I developed (not suggesting we replace the existing one), just that I will try to have a look and make improvements (or other changes) like the one you suggest, if that were to be accepted from the community/maintainers of course.
Collapse
28: Re: ajaxhelper and its tests (response to 26)
Posted by Jim Lynch on 04/02/15 09:35 PM
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

Collapse
29: Re: ajaxhelper and its tests (response to 28)
Posted by Antonio Pisano on 04/03/15 12:09 PM
We already have two separate procs to include js in head or in body, and for a good reason I think, as they must be put in different places on the page.

Javascript in head should never be replicated, as it is meant to be loaded and/or executed just once, while body could have multiple inclusions (js that should fire the same for each row in a table is an example)

I don't think there is need for merging the two procs in a more generical one. Some little code replication exists, but removing that could be as good as letting thing as they are, leaving space for further difference in script management.

Collapse
30: Re: ajaxhelper and its tests (response to 28)
Posted by Neophytos Demetriou on 04/03/15 12:34 PM
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.
Collapse
31: Re: ajaxhelper and its tests (response to 30)
Posted by Antonio Pisano on 04/04/15 02:52 PM
Neophytos Demetriou, I think I recall now I already gave a look at your slides some time ago. Your templating system seems very interesting!

Consider preparing/referring to a tutorial or other further documentation, as it could really encourage its usage and our feedback!

Collapse
32: Re: ajaxhelper and its tests (response to 31)
Posted by Neophytos Demetriou on 04/04/15 06:35 PM
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.