I am using customized Dojo library. When I load my client application, Dojo load the below two files after loading the "dojox/gfx/svg.js" file.
1. dojox/gfx/shape.js
2. dojox/gfx/path.js
Even though I have included these two files in to my Dojo Custom build, still these two files are always loading in to my client application.
I know the file "dojox/gfx/svg.js" will be load at run time based on the browser type, but why shape.js and path.js files are loading always at run time ?
Related
I ran into a caching issue for snap-ui.esm.js file. When we create a build in stencil.js we have to include 2 files on a page, snap-ui.js and snap-ui.esm.js.
The problem is that snap-ui.esm.js file contains links to other files that are loaded dynamically and their names are defined when creating the build. And if we created a new build, snap-ui.esm.js will contain another links already which is correct but browser may cache snap-ui.esm.js with links that don't exist already.
I assume this is not a stencil issue but i faced it during working with stencil.
Please advice how to prevent caching just one js file, in my case it is snap-ui.esm.js
I'm trying to follow the Compose Multiplatform Web Getting Started guide. Most of it seems to work fine, but when I try to actually run the thing (gradle jsBrowserRun), it starts a browser, but it can't find the generated JavaScript file. The browser console shows a 404 for GET http://localhost:8080/kotlin-multi-web.js.
The file kotlin-multi-web.js is indeed the name of a file generated in web/build/compileSync/main/developmentExecutable/kotlin.
The page title matches the one I defined in my index.html, so that gets loaded correctly.
I have tried a pure Compose Web project (which isn't a Gradle multi module project), and there it does all load correctly. I checked, and didn't see any differences between the Gradle build files other than the extra dependency from the web project on common.
So, why doesn't it load, and how can I fix it?
I have developed a vue application and did run npm run build
After that I uploaded the content in the dist file to my webpage but it returned a blank page.
Since I did this for testing I uploaded it to a folder in my public_html/mypage.com/vueapplication To get all the paths right I added a vue.config.js with this content:
// vue.config.js
module.exports = {
publicPath: '/vueapplication/'
}
The application now works but I wounder however:
how do I best publish/upload the application to my site? Just by simply dragging the content inte the right folder?
how can I best maintain my site? Do I need to build again and upload, overwriting my files when everytime I make an update on my site?
And what is the difference between build and deploy your application?
Drag and dropping your code should work. But as your app grows you may want to look into automating this. For instance if you use an S3 bucket you can use the aws cli to automate the upload.
Yes, you should overwrite your deploy folder(s). You need to also take care of deploying different binary files, that have the same name. An example is if you have a global css file (main.css for instance). The file will probably change content between deployments, but keep the same name. Browsers may cache the file so users that downloaded older versions of the file will not use the new one. There are different techniques to handle this, but if you use webpack, it uses cache busting techniques and you should be fine.
Build is the process of transforming source code into an artifact(s). Exactly what this means differs from language to language, platform to platform. In the vuejs world this usually means a couple of js files, a couple of css files and some assets.
Deploying means taking the output of a build and making it available to your users. Again this differs from project to project. In the vuejs world this usually means taking the artifacts from the build and uploading them to an http enabled web server.
Is it possible to use Dojo build without the need to modify JavaScript files?
The article dgrid and Dojo Nano Build provides the instruction to create the build, but it requires adding the following line into JavaScript file, which initializes the application:
require(['dgrid/dgrid'], function () {
(replacing 'dgrid/dgrid' with your build module name).
However, it is very problematic when using build for own modules, because, of course, in development mode the require with own layer can't be included, otherwise the modifications made to own modules wouldn't be visible. But in production mode this line must be added.
So either you must modify the file manually before production build, or write a script that would modify the file during the build. Both are very error-prone.
Is there a better way to achieve that result? Is it possible for Dojo to recognize that the build is provided and should be used, instead of loading each module separately?
The following line of code can be included in both development and production modes.
require(['dgrid/dgrid'], function () {
I describe the reasons why in my answer here.
What you need to do is configure Dojo differently based on what environment.
In a blog post that I wrote, I describe this in more detail. The following summarizes the post:
I create three modes: Production, Uncompressed, and Development.
Development
When developing code, I will have the js source linked into the web server and the Development mode will point to the dojo.js file and the raw css file(s). The browser will load modules that I need using xhr. And I point to the top level css files which import other css files. The result is that a lot of requests will be made to the server and the loading of the page will be noticeably slow. The benefit is that you can see development changes without having to do a full build.
Production
Production mode points the main dojo file at the dojo.js that is built using the build tool. I also create <script> elements for the other layers that are needed in the page. I point the css to the built css files which the build tool has inlined the imported css. The page loads quickly, but it is difficult to debug
Uncompressed
Similar to production, but I point to the .uncompressed.js files. Production and Uncompressed are available in the released version of our software. I use uncompressed when trying to troubleshoot an issue in a production environment. The value of this mode is dwindling as the developer tools are better supporting compressed javascript (ie source maps, etc.)
Server side
The default mode is Production, but I use a query parameter to switch modes. I also store the current mode in the session, so that I only have to set the mode once to change it. Subsequent pages will run in the changed mode, until I change it back.
Here is a java implementation of this code.
I'm doing a proof of concept app in SL4 using MEF and as part of the app I am importing another xap from an existing Silverlight Project and displaying it in my host project.
The problem is that the existing app uses some .xml files (as content) and it uses linq2xml to load these files which are (assumed to be) bundled in the xap.
When I compose the application the initalization fails because the host app doesn't contain the xml files. If I copy these xml files into the host project and run it the composition works fine. However, I need to keep the xml files in the original project.
Is there a way that I can download a xap and look at it's contents for xml files and then load them into the host xap at runtime so that after the compostion takes place the xml resources that are required can be found?
Or should I work out some kind of contract with an import/export to pass the xml files to the host xap?
As the people developing the imported xaps (should the project go ahead) are from a different company, I would like to keep changes to the way they develop their apps to a minimum.
I assume you are using the DeploymentCatalog to download the second xap? Unfortunately there's no way to get at resources included in that xap. You could have the resources embedded in assemblies which are included in the xap, and then modify the way they are loaded.
If you really don't want to change the way the secondary xap is structured, you might be able to write your own DeploymentCatalog which would also allow you to load resources from the downloaded xap. The source code to DeploymentCatalog is available, so you could base it off of that.
I've managed to find a solution that I'm fairly happy with.
Instead of building the .xml files as 'content' to go within the xap, I have built them as 'resource' then used Application.ResourceStream() and loaded the xml using a stream.
It means the second xap developers will have to change the way they operate, but its only one extra line of code and changing the Build Action, I'm sure they can handle.