Study on dynamic loading mechanism in ExtJS (RPM)

Think write too good, afraid lost, turn: http://extjs.org.cn/node/659

Yesterday, our team did some in-depth research on the dynamic loading mechanism of EXTJS, which share the results of the controller loading first.

Take the service registry Portlet as an example:
For example, in Liferay-portlet.xml, you define:

So the entry point of our JS is app.js, which creates the ext.application and declares the dynamic load controller:

View Source

Print?

1.Ext.application({

2.name: ‘serviceRegistry‘,

3.appFolder: ‘/serviceregistryportlet/js/app‘,

4.controllers:[‘mainPanel‘],

5.launch:function(){

6....

7.)

Here we look at how ExtJS is implementing dynamic load controller.

First we can see that when it loads the controller, all of the controllers declared here are passed to the Classnames property in the form of the full name of the class.

The config option for Ext.loader paths receives 2 properties, one is the default ext path, and its default value is defined as follows:

View Source

Print?

01.config: {

02.

03.enabled: false,

04.

05.disableCaching: true,

06.

07.disableCachingParam: ‘_dc‘,

08.

09.paths: {

10.‘Ext‘: ‘.‘

11.}

12.},

The other is the property obtained from Ext.application, whose key is the name defined in Ext.application (here is Serviceregistry),
Value is the Appfolder defined in Ext.application (here is/serviceregistryportlet/js/app)
As shown in the following:

Then in line No. 5314, another method Getprefix () is used to obtain its prefix based on the controller's class name, and the prefix will eventually participate in the operation. We omit this logic here, anyway, eventually, this "ServiceRegistry.controller.mainPanel" prefix is "serviceregistry", such as the debug results.

Note: All the above conclusions and yesterday I guess the exact same, yesterday did not debug the conclusion, it seems that my computer feels good, small proud of ~

Since the above paths gives 2 candidate path names (one is ext level, one is Project Serviceregistry level), these 2 pathname may be the alternate path to the final load resource file, then which path will be chosen as the final load path? It is necessary to look at the following analysis.

Just now because we've got prefix=serviceregistry, we finally get the name of the path that we really want to load by No. 5321 line: Path=paths[prefix], which is "/serviceregistryportlet/js/ App
Immediately after, class's name is also determined, that is, the class's full name (Classfullname) to remove the prefix (prefix), so that is "ServiceRegistry.controller.mainPanel", to remove " Serviceregistry ", left to" Controller.mainpanel ":
The above 2 information can be seen from the debugging results;

So the final work is clear, it will be all the path name in the "." Replace with "/" and then end with the ". js" file extension, so it will eventually become the resource path of the JS controller file:

This path is correct and we expect it to be.

So from the above debugging, we can summarize the following conclusions:
(1) for a controller, its load path always has 2 alternate paths, one is the alternate path of the Ext frame level, its default value is the current directory ".", the other is the project-level path, and the project-level path takes precedence over the frame level. The JS file is loaded from the frame level path only if the project-level path is not loaded into the JS resource file.

(2) for controller, to calculate the project level path, we have to obtain a lot of relevant information, such as prefix, Controller's class name, path name. Where Ext.application's project name (name) serves to provide the project-level path to the Key,ext.application (Appfolder) provides the value of the project-level path, and the prefix is parsed by the full name of the class.

(3) The prefix portion of the full name of the generic class is best consistent with the Ext.application project name (name), because the resource file's final path is computed through Path=paths[prefix]. If inconsistent, go to the Else branch.

(4) All resource file final paths are used. The split path is eventually replaced with a/split path and the trailing extension is appended to form, and no bare path strings are involved anywhere in the project.

(5) In any case the controller can always be loaded correctly, as long as the Appfolder is set correctly. For example, we set the name of Ext.application to "Hello", Appfolder is set to "/xxx/js/app", but we have a controller file, our prefix is not set to "Hello", but set to other , such as FXXK, so the controller's class name is "Fxxk.controller.ABCController", in this case. Prefix because it is parsed from the "Fxxk.controller.ABCController" string, so its value is "FXXK", and appname because it is "hello", so there are 2 values in paths, one is key= "Ext", Value= ".", the other one is key= "Hello", value= "/xxx/js/app", so when executing the path=paths[prefix] value, it is not able to get any value, so keep the original default value "" Empty string. However, ClassName is using "Fxxk.controller.ABCController" to remove prefix "fxxk", so classname is correct, or "controller." Abccontroller ", so in the last 5329 lines stitching path time: Path.replace (Slashdotslashre, '/') still return" ", and classname is correct, so Classname.replace ( Dotre, "/"), will return/controller/abccontroller. Finally splicing the. js extension. So this file will still load correctly.

Author: the cohesion of parallel lines
Original: http://supercharles888.blog.51cto.com/609344/1244064

Study on dynamic loading mechanism in ExtJS (RPM)