JLA framework introduction (iii) Resource reference and sprite Mode

Previous ArticleArticle, I introducedCodeWhy do we need such a unit specification? The main purpose is to split the code and functions in a systematic manner, so that each code unit only pays attention to its own logic, so as to improve the reusability of the Code.

 

However, it is far from enough to implement a framework specification so that every code unit can start to implement its own logic, we must provide a reasonable solution to the problems that most code units are concerned with, so that the code units do not worry about these issues any more, the two most important solutions are resource management and configuration management. I will talk about Configuration Management in the next article. This article will first talk about resource management.

 

In this frameworkProgramJavascript is the main body, but JavaScript alone cannot implement those rich and colorful applications. It is common to call images, CSS or other resources. That is to say, in addition to a JS file, a program unit (or class) may have a series of images, CSS fragment files, music videos, and other content (collectively referred to as resource files) it is combined with a script file to form a program unit. If you need to consider code reuse and independence, these resource files should also be taken into account.

 

For resource calls, I have designed such a solution:

1. during development, it is assumed that the resource files and class files are stored in different directories. For example, for the namespace com. Test. classa, the class file path is:

Workspace/src/COM/test/classa. Js

Assume that a picture test.png is used for classa, which should be placed in:

Workspace/resource/COM/test/classa/Test.png

In this way, each class has its own resource directory. You can put multiple resources under the directory without worrying about conflicts with other file names.

2. if the class classa wants to call its own resources, of course, you cannot directly write the path (if you write the path directly, it basically cannot ensure that the code can be executed after the code is deployed or moved ), it is recommended that classa require when definingJS. ResourceClass, and then call the static method geturl of the class, for example:

 

 1 JLA. Require (["JS. Resource","Namespace. classb"],2,Function(Resource, classb)

2 {
3 // Code of classd start
4 Function APP ()
5 {
6 VaR IMG = Document. createelement ( " IMG " );
7 IMG. SRC = Resource. geturl (app, " Test.png " );
8 }
9 App. Prototype. onclick = Function ()
10 {
11 JLA. Require ([ " Namespace. classc " ], 1 , Function (Classc)
12 {
13 // Call classc.
14 })
15 }
16 // Code of classd end
17 JLA. Set ( " Namespace. classd " , APP );
18 })

 

 

In the example code, an image object is created and the URL is set to test.png in the resource folder. The first parameter of the geturl function is the namespace of the class or class. Generally, we do not want a class to care too much about what its namespace is, we recommend that you use your own class. The second parameter is the resource name, which is generally the corresponding file name. Based on the two parameters, the resource class accountant calculates the URL address of the resource file and returns it, in this way, the code unit no longer needs to care about the specific location of its resource files.

When the code is finally deployed, the resource access path and organization form may be different from the Development Mode. In this case, you only need to change the resource class configuration or override the geturl method at the time of release, so that each code unit can normally access its own resources, and each code unit does not need to be changed. In addition, according to the require relationship of the Code unit, the corresponding resources do not need to be released to the deployment environment.

The above is a solution for resources. This solution simplifies the relationship between code units and resources, bringing a lot of convenience.

 

One of the problems that comes with the following is Sprite. Based on the existing framework, I hope to store resources of different code units in different directories. However, on many websites, by combining multiple images (probably unrelated) into one image, it seems difficult to effectively split the code, I propose the following solutions:

 

First of all, I think sprite should not be the content that needs to be considered during development, but the content that needs to be considered during deployment. Therefore, I do not recommend that you use merged images when developing code units. This will greatly reduce code reusability. It is best to separate images one by one during development, each code unit calls its own resource image. It is not recommended to use sprite technology even inside the code unit, because I have said:Sprite should not be the content to be considered during development, but the content to be considered during deployment..

Now, assuming that the sprite issue has not been taken into account during the development of each program unit, how can we implement Sprite? I want to use a technology similar to Rewriting:

1. assume that each code unit uses a JS class when displaying images. HTML. image. This class provides three methods: Create (used to create an image instance based on the URL), setsrc (used to change the SRC of an image instance), and setbackground (used to set the background image, these three methods contain the basic usage of all images.

2. js. html. image also provides an addsprite method to notify the image class of which images are integrated into another image, for example:

1 Image. addsprite ( " IMG/image.png " ,[
2 {Rect :[ 0 , 256 , 300 , 44 ], Path: resource. geturl ( " Test. class1 " , " Test.png " )},
3 {Rect :[ 0 , 212 , 300 , 44 ], Path: resource. geturl ( " Test. class2 " , " Test.png " )},
4 ], {Size: {X: 300 , Y: 300 }})

 

In this case, the imageclass records this information. When creating the test.png image of test.class1IMG/image.png to obtain the image display, so as to implement the sprite scheme of the image.

In doing so, I think there are more advantages than general sprite solutions:

1. It has nothing to do with the development process, so that the development process will not be affected. When we need to know the sprite technology on the internet, it indicates that the disadvantage is to complicate development and maintenance.

2. If the sprite image has been adjusted, you only need to modify the above configuration and do not need to adjust it everywhere.

3. Combining completely unrelated functions is not a problem at all.

 

In this way, the sprite technology in this mode is implemented. The source code of this key image object should be displayed, but this is not complete yet, this series of articles mainly introduces the idea of the new framework. The source code is not very important, and it is not too complicated to write it out.