Currently, with my Intern setup, I'm using an unbuilt Dojo build when running my Intern tests; like, for example, a test module loads app/ProductModuleA, and ProductModuleA references and loads dojo/request. I need to have the dojo/request.js file in the appropriate directory structure in order for the module to be resolved without errors and therefore the test to be able to run. Our product code does use a built dojo.js file and our previous DOH tests were able to use this, too, without any issues--I don't understand how that worked because I don't know anything really about building Dojo.
I know I've seen snippets in various Internet forums (like here) and the Intern User Guide that Intern supports source maps, which I guess suggests it's possible to use a built dojo.js file in conjunction with running Intern, but I haven't found anything at all in detail. Insights, or pointers to documentation or examples that so far I haven't been able to find?
One of the benefits of AMD is that you don't have to do anything special to your code when switching between a built and unbuilt Dojo. The first time you load a dependency using an unbuilt Dojo, the loader requests it over the network and then caches the result. Subsequent loads use the cached dependency. The loading process works the same with a built Dojo; the main difference is that all the modules built into the built Dojo are pre-cached. The loader doesn't have to request them over the network the first time because they start out in the module cache.
For Intern to use a built Dojo, you just need to make sure you're using the built Dojo as your loader during tests. You can do this by setting the useLoader option in your Intern config.
I tried what Jason suggested and it still didn't work--I was getting 404s for a Dojo_ROOT.js module, though nothing in tests or product files explicitly load that. I'm sure this is due to something unique in my product's build environment. That's okay, I will just use the Dojo source for now and return to this later.
Related
I'd like to integrate VueJS through WebPack in one of my custom Odoo modules, and have it start up automatically when I launch Odoo-bin.
Does anyone have a solution?
Is it even possible?
I know you can include VueJS as a simple .JS file in the module's template, but that means I can't use the .vue components supported by WebPack.
I also read that Odoo has its own JS framework, but I couldn't find good tutorials/documentation for it.
EDIT: To anyone that might be wondering how I solved this, here's what I did:
I initialized a package.json file in the root of my Odoo folder using npm init. I added a start script to the package that launches webpack and bundles all vue components in myAddons folder (where I store my custom modules), then launches Odoo through the python odoo-bin ... command. All that's left is to use npm start to start it all up.
This way, the vue components get bundled into single JS files, that I then add to the templates of my modules. This has a small inconvenient in that the first bundle has to be done manually in order to know which JS files need to be imported to the templates. Also, i'm still trying to figure out how to bundle the components of every single module separately. Will update this once I find a proper way to do it. ...Hopefully.
By default, odoo frontend part is heavily built upon backbone, jquery, underscore. If you want to use any other JS library, you have to make sure the compatibility in between them. The odoo backend parts of JS functionalities are written under web module can be found in odoo/addons/web/static/src/js directory in odoo community codes. The ecommerce/website part is under website* modules.
Along with the fact that the Odoo JS API documentation is basically non-existent (as of the time I am posting this) .. I would add the fact that its going to be like working with a moving target compared to calling Odoo's JSON-RPC API directly since their JSON-RPC API changes very little over different versions of Odoo.
Moreover, making JSON-RPC API calls with Axios is extremely simple. So just go directly to the server's JSON-RPC API from your Vue project.
This is what I am doing with at odooinvue.org which is basically a Vue project that uses Odoo in the back-end. That project is designed specifically as a resource for Vue developers that are trying to use Odoo in the back-end but have difficulty because they are new to Odoo development.
I suggest trying #StartupGuy's odooinvue, which is really nice.
With Odoo 14 they created a new modern frontend framework: Owl framework.
I have not tried it myself.
I am curious to know why when I create a new Aurelia project, each project installs +600 node_modules. Understandably, the modules collectively don't take up a lot of space, but are all of these modules necessary? I was under the impression that Aurelia's aim was to help developers move away from depending on 3rd party libraries so it seems odd that each project comes with a massive dump of 3rd party libraries.
My guess is that you are starting your project from CLI - which comes preset with HTTP server, ES6/2015, SASS, live-reloading and more.
I created clean Aurelia project and looked at the package.json - there were 5 dependencies and 34 dev dependencies. Using all of above mentioned tools is somewhat standard in today's JS web development, and generating project from CLI reduces time needed for upfront setup. All of these features come with their own dependencies, and that's why node_modules/ folder grows rapidly.
The bottom line is - you could start new Aureila project with much fewer dependencies. On their home page you can find starter project with just three. But that also means that you won't have access to most of the tools used today.
Also, and correct me if I'm wrong, I haven't got the impression Aurelia ever aimed to move devs from third party libs and modules, just to be modern, fast, and unobtrusive.
All modern web frameworks have a host of tooling. The reasons in no particular order -
1. Transpiling ESNext or TypeScript - if you want to write in Future JavaScript but have it work in all browsers, you need this step. Both Babel and TypeScript tooling comes with extra stuff too. If you want to see coverage (everyone does) there's another tool.
2. Testing - Unit test and End to End testing require testing frameworks, test runners, and if you want to write like above (esnext or TypeScript) you also need transpiling.
3. Module Loading / Bundling - Require.js, JSPM/System.js, WebPack, etc... are used to allow your code to actually run in the browser. Without a module loader you could not break your code out in to separate files. Without a bundler you would be loading a lot of extra files in production.
4. Serving your application - If you want to run your app locally you need a way to serve it up and watch for changes.
5. Debugging - You want to debug? Now you need a way to debug the file that gets served to the browser back to the original source.
6. Linting - Lint your code base for style consistencies.
Each of these packages usually have their own dependencies, and they get pulled down as well.
This convention of small packages that have a single focus is arguably better than massive packages that do everything for you. This allows you to remove a package and replace it with the one that does the same thing but in a way you want it.
I am trying to manage my dependencies of my play framework application. I am trying to remove/update some jar that exists in my classpath. Does that even possible?
It would be great to get an explanation of how does play framework manages classloaders. I understood that in order to obtain hot redeployment of code in development mode Play is restarting the application classloader and loads all classes again. Does it right?
Thanks a lot!
It's not really Play managing the hot reloading but rather the Play SBT plugin.
A Play application's main method is in play.core.server.NettyServer. The method receives a reloader of type SBTLink and each time a request hits the server, the application delegates the task of checking if there have been any code changes to the reloader.
If there has been a code change then the existing classloader is removed and replaced with a new one which includes the updated bytecode. The application is restarted but, of course, the JVM is not.
Play is not designed to provision dynamic swapping of Jars at runtime. For this, you would need to look at things like OSGi (which I would not personally recommend after a few years of working with it).
I want to compile coffeescript from my Mac OSX app, but I'm unsure how to go about doing this. It seems like node tasks are heavily dependent on other libraries installed to the system. How can I go about compiling coffeescript files from my app?
A couple ideas:
The 'Try Coffeescript' section on coffeescript.org compiles in the browser by including the coffeescript compiler as a javascript tag. You could do something like that in a UIKit WebView where you have control over the javascript execution.
PhoneGap/Codova based app
Make a request out to a node server or other js environment and return the compiled code via service call.
I'm not sure you've provided enough context for which one of these might work, but they are the first things that come to mind.
WHere can I get a XD version of dojo source like the one hosted on google? What I want to do is to host dojo source from my local CDN, and my custom dojo module in my web application. Is this a good practice? or I might as well just include the dojo source in my web app, and run the custom build?
Thanks,
You can build an xd version of dojo from the source code
Here are instructions on how to do it:
http://dojotoolkit.org/reference-guide/1.7/quickstart/custom-builds.html
See the section on "doing xdomain builds"
In our organization (a large one), we do have a CDN version of dojo deployed on internal CDN mainly since some of our webapps are not allowed to access extranet (firewall issues).
For performance, though, a custom build gives biggest boost since it is customized to the modules you need/use - once the custom build is done, you only need to ship a single compressed js output file and a small number of supporting files
When doing your custom build, you can use the xdDojoPath and loader=xdomain if you wish to use cross domain dojo to load your optimized js - see http://osdir.com/ml/cometd-users/2011-08/msg00050.html for some notes on this
Also see related SO question: Dojo on a CDN vs own install
The good news is that with Dojo 1.7+ and the new loader, you don't have to do anything special for a cross domain build (good answer above from #Vijay Agrawal, but I think that reference guide link may need some updating for 1.7) Just write your code to the new AMD format, use asynch:true, run the build tools to create layers, and deploy them on any server. AMD makes use of callbacks and many of the tricks the old Dojo xd builder used to employ, but in a much simpler way.
To support older code, there is a legacy cross domain mode mentioned in the loader docs.