Hi No errors now, but do you know why JS tests are being skipped?
PhantomJS 2.1.1 (Mac OS X 0.0.0): Executed 4 of 216 (skipped 212) SUCCESS (0.085 secs / 0.046 secs) Thanks! On Mon, Jul 17, 2017 at 12:07 PM, Surinder Kumar < surinder.ku...@enterprisedb.com> wrote: > Hi Dave, > > I didn't removed the vendor modules when i ran regression test cases, so > modules were being referenced from vendor dir and passed for me. > Now I have fixed path references and test cases are working. > > Please find attached patch. > > Thanks > Surinder > > On Mon, Jul 17, 2017 at 3:18 PM, Surinder Kumar < > surinder.ku...@enterprisedb.com> wrote: > >> Hi >> >> I'm currently working on first TODO: "Automatically handle static and >> template JS files" >> >> As discussed with Ashesh, currently the paths to module id are written >> manually in webpack.config.js, instead the path defined in moudle's `def >> get_own_javascript()` should be used. >> >> So, we will be generating a paths.json file which will contain: >> >> 1. resolve > alias - path with reference to module id.(Static files) >> >> 2. externals - list of modules to be loaded dynamically on >> demand(Template files) >> >> 3. Shim module dependency >> >> 4. List of JS modules to be loaded in specified order. >> >> *Implementation:* >> >> To generate `paths.json` file, we will be using `Flask's test_client` to >> make an http request internally within the app context so we can call >> `current_app.javascripts` property and return the list of JS paths and >> write those into paths.json file and then use it in webpack.shim.js before >> the execution of `yarn run bundle` in `javascript_bundler.py` >> >> *For example:* >> >> @app.route('/get_script_paths') >> def get_script_paths(): >> from flask import current_app >> from pgadmin.utils.ajax import make_json_response >> >> return make_json_response(data=current_app.javascripts) >> >> if config.DEBUG: >> with app.test_client() as client: >> import simplejson as json >> list_scripts = client.get('/get_script_paths') >> scripts = json.loads(list_scripts.data) >> >> javascriptBundler = JavascriptBundler() >> javascriptBundler.bundle(scripts['data']) >> >> >> This also needs little change in module dependency we defined using >> 'When': 'node_name' in `def get_own_javascripts(...)` method >> the module specified(name: module_name) is loaded when module given in >> `When` is expanded in node. Since we are using Webpack in which behaviour >> to load module is little different. >> >> Now in webpack we are using `imports-loader` to load specific modules. So >> this is how it should work. >> >> 1. First load all modules which do not have dependency on any node like >> 'about', 'dashboard', 'server-group', 'server' etc. >> >> 2. Load module such as `Databases` node first before its child nodes are >> loaded. >> Similarly load `Schemas` node before its child nodes are loaded as they >> are dependent on parent node. >> >> Thanks, >> Surinder >> On Wed, Jul 5, 2017 at 8:22 PM, Sarah McAlear <smcal...@pivotal.io> >> wrote: >> >>> Hello, >>> >>> >>>> *Things to discuss:* >>>> >>>> How to differentiate between a static and template JS >>>> >>>> . >>>> >>> >>> What is the advantage of webpacking templated JS? It seems as though >>> this creates a system in which the bundled dependencies have to refer back >>> to the backend to load the templates. >>> >> Templated JS will not be part of generated bundle JS, they will load >> externally( an extra request will be made to server For example: >> translations.js) >> >>> >>> If there is a performance win in packing templated JS then looking at it >>> makes sense. Otherwise it may make sense to put off until it is clear that >>> the templated files should be dealt with by either de-templating them or >>> bundling them where there is a clear reason. >>> >> Template JS cannot be bundled, so i extract the <Jinja> code from >> template files and put into a separate file - ABC.js (also moved template >> files to static directory) and then load ABC.js dynamically as dependency >> of other modules. >> >>> >>> However, we're wondering about possible performance penalties with >>> templating larger files (as opposed to templating on-demand.) Since jinja >>> templates can execute arbitrary python, this could get time expensive and >>> further slow things like initial page-load. >>> Another concern is: what happens when a template gets out of date (e.g. >>> if browser.js had previously filled in the content for 'panel_item.content' >>> and had been cached, would it render a new version with the new values when >>> needed? Or is it possible that we would get old content?) >>> >> That file will always gets new content when loaded dynamically, the >> content is not cached. >> >>> >>> >>>> *Taks remaining:* >>>> >>>> 1. >>>> Fix local variables which are declared without using var, have to check >>>> in each file >>>> by >>>> running eslint (For now, i will fix only errors which are giving error >>>> in browser). >>>> >>>> 2. >>>> Move non-template files from ’templates’ to ’static’ directory. List of >>>> pending >>>> modules is here: >>>> >>>> - Tools (mostly all modules - 9 modules) >>>> - Browser nodes - 3 modules(resource group, roles, tablespace) >>>> - About >>>> >>>> >>>> Also can we move >>>> ' >>>> dashboard, statistic >>>> s >>>> , preferences and help >>>> ' >>>> modules inside misc to preserve modularity as pgAdmin is modular >>>> ? >>>> >>> >>> Is there anything from a organization stance you discussed in the >>> previous email that needs to be done to make this usable and consistent? >>> >> No >> >>> >>> >>> Thanks, >>> >>> George & Sarah >>> >> >> > -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company