On Mon, Jul 17, 2017 at 4:52 PM, Dave Page <dp...@pgadmin.org> wrote:
> Hi > > No errors now, but do you know why JS tests are being skipped? > No errors/warning in console even after settings `logLevel: config.LOG_DEBUG`. I am still debugging. > > 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 >