Ticket #837 (new enhancement)

Opened 3 years ago

Last modified 2 years ago

Refactoring CSS and JavaScript declaration

Reported by: bdelbosc Assigned to: madarche
Priority: P2 Milestone: CPS 3.5.0
Component: CPSDefault Version: TRUNK
Severity: normal Keywords: css js javascript
Cc:

Description

Refactoring CSS and JavaScript? declaration

At the moment the current situation is that all the CSS and JavaScript? declarations are almost done in 2 files: default.css and functions.js in CPSDefault while every CPS Products should be able to declare one or more css and javascript files.

So we should set up a framework that will take in charge the subscription of products' CSS and JS files and their rendering.

From those multiple CSS and JS files this framework will generate only one unique CSS file and one unique JS file.

This framework should keep a common stylesheet_properties.props for the sake of factorization.

Rationale:

  • each product will have its own CSS and JS files defined in itself and not in CPSDefault.
  • the generated unique CSS file and JS file will be smaller than the current files than currently include unused products' styles.

Change History

07/19/05 14:43:53 changed by fguillaume

Note that Plone has such a framework. It's called ResourceRegistries (http://svn.plone.org/view/plone/ResourceRegistries/trunk/)

07/19/05 18:45:14 changed by fguillaume

Note also that we have the problem of providing appropriate javascript to the widgets themselves.

07/19/05 19:18:46 changed by jmorliaguet

oui, c'est une bonne idée.

je vais essayer de voir les cas possibles, mais de manière générale:

- dans le cas des portlets, le code javascript est généré en fonction des portlets effectivement affichés sur la page (voir par.ex le code javascript de la searchbox). Donc tout ce qui est autour de la partie centrale de l'écran (c.ad les portlets) est déjà géré par cpsskins/cpsportlets. Le code CSS statique pourrait être enregistré de manière plus générique.

sinon dans la partie centrale :

- pour les formulaires (login_form, search_form...), il suffit d'avoir un forms.css, forms.js commun dans CPSDefault, et l'équivalent dans CPSDocument pour l'édition et l'affichage des documents.

- il est possible d'associer les css/js aux produits installés, mais c'est pas forcément optimal. Peut-être qu'il serait mieux d'inclure les css/js en fonction du content-type affiché (chat / webmail / calendar, ...).

le 'portal_css' de Plone2.1 par exemple a un champ "Expression" pour l'inclusion conditionnelle des fichiers css (mais il manque la partie javascript).

02/22/06 20:15:54 changed by ebarroca

  • owner changed from trac to tziade.
  • milestone changed from unspecified to CPS 3.4.1.

05/16/06 19:36:59 changed by sfermigier

  • milestone changed from CPS 3.4.1 to CPS 3.4.2.

Il believe this is a work in progress by tziade (Nuxeo JS library).

11/03/06 14:59:01 changed by scamps

In the ticket #1757 I've suggested to include widget javascript requeriments in the widget render function itself, so the widget will not depend on javascript includes done by the template where it is used. One way to implement that could be to have an "importModule" function, able to detect if a javascript file has already included, and loading each file just once. As an example of that way of work, there is the loadScript function in CPSPortlets/browser/tree.pt, or the importModule function defined in the init.js of jsolait javascript library.

11/03/06 15:30:58 changed by madarche

  • owner changed from tziade to madarche.
  • milestone changed from CPS 3.4.3 to CPS 3.4.4.

03/26/07 17:00:17 changed by jmorliaguet

considering javascript resources, there is a simple optimization that can be done:

for a given site, go through all portlets, gather the javascript resources into a single file and place them in a global "per site" cache. The cache needs to be invalidated when a portlet is modified / added / removed.

Note that some existing sites might break (in cases where the javascript code is dependent on the actual HTML content of the page, this can happen), so this ought to be implemented as a new option for instance in the theme's tool (for example: [x] use a global file for javascript resources).

that's a "pull" model since you collect all resources from existing portlets. The advantage is that it is easy to implement, it only requires small modifications from the existing code, the drawback is that it can lead to a large javascript file, but thanks to the server-side cache and the browser cache / gzip possibilities it really doesn't matter.

the other model is to push resources into the <head> of the page, it is the way I would implement it today, as long as the result of the concatenation of all the resources can be easily cached per key (that's the case in nxthemes where resources are per theme/page/perspective/mode).

for CSS the issue is different since portlets do not declare CSS resources