Forum OpenACS Q&A: Re: ajaxhelper and its tests
in blank-master.tcl with
A little shortcoming with this is that template::head::add_script handles multiple inclusions of the same script and also their order of inclusion, while template::add_body_script doesn't.
If my change seems legit to you people I can commit
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)
To serve the community perhaps a transitional approach should be used.
Apply the change for core.js, since that is the one required script and has no conflicts with (any) existing template::add_body_script calls.
All the best
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.
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.
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.
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 )
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?
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
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 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?
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.
Consider preparing/referring to a tutorial or other further documentation, as it could really encourage its usage and our feedback!