When deploying an enterprise Durandal application with hundreds of views, is there a way to bundle the html templates so that little http requests for every view can be avoided in favor of a single, compiled html view?
With Durandal, you're developing a single-page application, so there's only one, up-front request made for views. Caching and other optimizations, including optimization with Weyland, Durandal's build system, can tweak that further.
There are circumstances where you may wish to load views in a different way, and those can be achieved with Durandal as well.
After you built your app with, for example, Grunt (http://durandaljs.com/documentation/Grunt.html) you are getting one big file 'main-built.js' with all your javascripts buldled together. The thing that I didn't realise at first, was that all the .html views are also bundled into this file. I was expecting to see them bundled into 'index.html' or something like that (compiled html view). But actually views are compiled into Javascript.
Related
I would like to ask what is the best approach to include and reuse Vue components that are written in .vue files (SFC), into existing web pages.
For example lets say there is already an SPA project and also an ASP Core project. I would like to reuse my ~/SPA Dir/components/*.vue into my Razor pages or just plain HTML pages. To be more specific the web pages are using Vue through the CDN js file.
In most Vue tutorials it is often mentioned how Vue is used to create SPAs or it can be used in already existing web pages. And there is also emphasis on the reusability of its' components. But it seems very frustrating and complex to follow those guidelines with often lacking and unclear guides.
From my research I realize that there must be an intermediate build process that will produce js files form the vue files. And also the need of tools like vue-loader and webpack. But still I could not find something straight to the point.
Is there a more straightforward approach or what is the most common approach to the above-mentioned scenario.
(Vue version: 3)
Thank you
Maybe try this SFC loader: https://github.com/FranckFreiburger/vue3-sfc-loader
I use it on my PHP server, where I have my .vue components and I need to compile them as .js.
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.
I had this question ever since I learnt about Erlang and it's possibility for hot replacements of separate modules and even functions on a production server.
We are developing a project in Java for Glassfish 2.1. It's basically an .ear file consisting of a bunch of .war modules.
So, every time, I make a minor change in the code of one of the modules, in order to check that change I have to redeploy the whole ear on my development server. Is that really how it's supposed to work?
Basically we have several levels of replacement - are they even possible?
The war module. Happens during a big number of commits by several developers. Is it possible to replace just this module on the working server without redeploying the whole ear file.
The java classes (action handles and etc). Is it possible just to replace the bytecode of the classes that were changed?
The jsp pages. I think they are launched indepently by the special jsp interpreter in glassfish. So this one definitely should have the possibility of the hot reload of a single changed page.
I know I can perfectly replace the different parts of HTML design, such as css or js files, or image files. But what about the bytecode files described above?
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.
I have recently been browsing frameworks such as JavaScriptMVC, qooxdoo, Sproutcore and others alike which are using javascript to create desktop-like apps in the browser with minimal, or none css/html (depending on the framework).
What I know of titanium is that it uses html/css for the views, and language of choice (javascript, ruby,python,php) for everything else. Then it gets compiled(?) into a native app.
What are the quirks? if any?
Is it necessary for the user to install some sort of a runtime to execute the compiled app?
I suppose javascript is the prefered language, but how are the other ones handled?
For example, which Ruby interpreter would be included, would I be albe to use the ruby stdlib or external libraries? Would it affect the speed of the app? I.e JS > Ruby in terms of speed.
Since the views are CSS/HTML, would it still be necessary to style the elements, add them effects via JS librarier to achieve a widget-like feeling? Or does it come with some pre-made settings/classes for that?
I am not sure if it applies to the desktop package, but is there some syncing with the appcelerator's server required? What would it be necessary for?
I am sorry if the questions sound stupid, but I didn't even realise there are than many tools until recent. I am ultimately looking for something which is easy to use, has an option to work with a back-end server for data exchange, looks preferably good 'out of the box' or doesnt require that much work to get it themed nicely and works on mobile as well as desktop devices.
With Titanium you build your app out using javascript. Titanium ultimately generates its own XCode project for you that is compiled and deployed to a device.
The user does not require any runtime be installed prior to installing your app.
Unless your building custom modules to hook up your own controls you stick with javascript.
Your javascript calls end up as native controls, early versions required css like styling due to reliance on webkit but this is no longer the case.
There is no IDE but it does come with an app to create Titanium projects, test in emulator, deploy etc. It also talks back to HQ for updates.
In answer to (2), Titanium Mobile is Javascript only, but Desktop also supports Python, Perl and PHP.