Bug 368555

Comment 1 Brian Svihovec 2012-01-23 16:28:15 EST

Additional Thoughts:

 1) Benefits Dynamic Loading when the list of handlers used at runtime is calculated by the application
  2) Improves the content of the HTML file by removing long lists of required .js files
  3) Benefits re-using RUIHandlers in existing Web 2.0 applications - just need to reference a single .js file for the RUIHandler and not add more than one requires to their HTML file
  4) egl.require uses type names/modules and not .js files - egl.requires determines what files need to be loaded
  5) modules can be loaded as a single bundle (multiple .js files in 1 request from the browser to the server)

Comment 2 Tony Chen 2012-02-03 05:24:02 EST

Created attachment 210501 [details]
design doc

Comment 3 Tony Chen 2012-02-03 05:32:25 EST

Created attachment 210502 [details]
sample to validate some of the design

java runtime jar was removed from SimpleDeploy\WebContent\WEB-INF\lib so that the file size meet the attachment limit. There's not much to see in SimpleDeploy. It is no more then a deployed EGL project, for comparison purpose here. 

SimpleDeployAMD & SimpleDeployAMDOptimized can be run on an Tomcat, or by open the HTML file directly with a Browser.

Comment 4 Will Smythe 2012-02-03 21:25:09 EST

This looks really cool! Questions:

1) How is the AMD version going to work once Dojo is in the picture? I assume we'd want Dojo to load via AMD as well, right?

2) How do we expect dynamic loading to work with AMD?

3) Will we use RequireJS's suggested minification technology (see http://requirejs.org/docs/optimization.html)

#2 and #3 in Brian's comments are really important. We need to start assuming that people will want to reuse EGL-generated logic/UIs in other web pages.

Comment 5 Tony Chen 2012-02-06 09:15:53 EST

Created attachment 210582 [details]
Sample to integrate dojo app & egl rui app

I did some interesting experiment to run an EGL RUI handler in a Dojo app, here is it: 

1. I took a dojo sample from its website, the sample uses dojo 1.7.1 from Google CDN. 
2. I then tried to load my AMD version egl modules(from the previous sample) using the Dojo AMD Loader. After fixing some package mapping issues, it finally works and shows content from both the dojo sample and EGL RUI Handler. 


The interesting finding is that dojo 1.7 AMD loader worked just well as the RequireJS AMD loader which I used in the previous sample. It further demonstrate that once the modules are define in the AMD way, any well implemented AMD loader will be able to load it. 

To run the sample, just open DojoApp.html in a browser. You may need to update the egl path root value based on the instruction on the page.

Comment 6 Tony Chen 2012-02-06 09:29:25 EST

(In reply to comment #4)
> This looks really cool! Questions:
> 
> 1) How is the AMD version going to work once Dojo is in the picture? I assume
> we'd want Dojo to load via AMD as well, right?

See the sample in comment 5, it's quite clean and straight forward. 

> 
> 2) How do we expect dynamic loading to work with AMD?

I assume you are talking about the runtime dynamic loading, which is to load a module only when our application executed to the line that needs the module. I still need to investigate how would work. 

> 
> 3) Will we use RequireJS's suggested minification technology (see
> http://requirejs.org/docs/optimization.html)

I think we should. The most interesting optimization to me is to package all the dependent js into one file. With this, we can deploy just a few files instead of copying all js as we did today. It's also a good solution to Bug 368167, once the runtime are in modules, the optimization tool will help us package and deploy those necessary ones. 

optimization also does minification like what we did with DojoShrinksafe. 

> 
> #2 and #3 in Brian's comments are really important. We need to start assuming
> that people will want to reuse EGL-generated logic/UIs in other web pages.

If you look at the sample in comment 5, both #2 & #3 are done quite nicely. 

There's actually a few more question, mostly related to VE
1) how do we reload a handler(and only the handler)? We can do this in VE because we control the loading, now, we have to go through the Loader. 
2) how do we let the loader know the VE context (through giving a contextKey)
3) handle includeFiles, some experiment is needed here

Comment 7 Tony Chen 2012-02-09 22:10:15 EST

Created attachment 210832 [details]
updated design doc

Comment 8 Tony Chen 2012-02-10 02:40:44 EST

The plan is to implement the core AMD support in 0.8 I3 which are split into below enhancements: 

bug 371167	Generate JS into AMD modules
bug 371173	Use AMD loader in HTML to load modules
bug 368001	Only use contextKey to load parts in the file being displayed in VE
bug 371174	Redesign handler reloads to work with AMD module loader

extended feature like optimization & dynamic loading will be based on these core support.

Comment 9 Huang Ji Yong 2012-02-27 09:24:06 EST

Created attachment 211666 [details]
Patch for the whole solution

The functional work for this bub is almost finished.
Check the patch for code change.
Check the testproject.zip for the new Dojo projects of local and remote and a test project.
Check the sample.zip for some generated js and html sample and dojo external js sample.
Check Modular Loading status.doc for detail design and changes.

Comment 10 Huang Ji Yong 2012-02-27 09:25:01 EST

Created attachment 211667 [details]
Design & changes for modular loading

Comment 11 Huang Ji Yong 2012-02-27 09:33:37 EST

Created attachment 211669 [details]
sample generated files

Comment 12 Huang Ji Yong 2012-02-27 20:32:51 EST

Created attachment 211702 [details]
Test project. Include the dojo projects

Comment 13 Huang Ji Yong 2012-02-28 04:52:01 EST

Created attachment 211713 [details]
Updated patch

Update:
Finish all coding.
Roughly test RUI samples & Dojo samples, all works.
Will do more testing tomorrow. Forest will do a performance testing.

All code changes are contain in patchModular02281729.txt
Notice that there are also code changes in widget/sample projects. Please use the widgetprojects.zip to test.
The widget project includes the changes of Dojo 1.7 update, Dojo local runtime optimize(364415) and Dojo externalType AMD header. These 3 changes are made by lulu.

Highly Concern changes (check design doc for detail
1. ExternalType
External JS is not generated, user have to change the existing external js file if the external type has parent type or/and include file.
2. Dojo.js as loader may cause some EGL packages fail.
EGL package name can not start with "dojo", "dijit", "dojox"
We may be able to have workaround for this problem, such as make an alias in gen, modify the path in EVServer etc. But first, we should identify that this is a problem.

Comment 14 Huang Ji Yong 2012-02-28 05:00:11 EST

Created attachment 211714 [details]
The widgets and samples project modified with modular style

Comment 15 Huang Ji Yong 2012-03-01 08:31:34 EST

Created attachment 211870 [details]
patch updated in Mar 1st

Comment 16 Huang Ji Yong 2012-03-05 01:57:30 EST

Created attachment 212048 [details]
The patch that is committed in Mar 5th

Update the patch that is committed.

Comment 17 Huang Ji Yong 2012-03-05 01:59:43 EST

Resolve. Additional problems if found will be opened as bugs

Comment 18 Huang Ji Yong 2012-03-09 02:53:22 EST

Verified in build 0.8.0.v201203082103-1DS-FjuJ6QMOCq5RWy3dGC8K