Are there any known procedures to achieve this. Application is being automatically build by Jenkins. Only possible way I could remember is changing file names but this is not preferable option.
I would probably go for cache manifest file. Ext 5 production build already contains some basic setup, however, you would need to adjust it to your needs.
Rule of thumb: If the manifest file changes, the app is refreshed.
For more info see A Beginner's Guide to Using the Application Cache or google for "cache manifest".
Related
By default, when a React Application is deployed, the cached version will display, even if changes were made in the new build. This requires the end user to hard-refresh their page (Ctrl+F5) to see new changes. It is not feasible to have a user do this each time.
With the constant upgrades and speed of software evolving, there are many different ways to accomplish this. However, the answers widely vary due to different practices being used each year.
What is the best practice to accomplish this in 2022? Is there a short and easy way to do this?
Edit: I am using the create-react-app project template.
This has to do with broswer caching the old pages and not React, to avoid this you need to either force refresh as you mentioned or changing your build strategy with some sort of different file naming, this can be done by using webpack caching here https://webpack.js.org/guides/caching/.
This way your scripts will have different names with each new deployment and the browser will ahve to reload the new scripts when fetching the index.html.
What is the best way to dynamically provide configuration to a vespa application?
It seems that the only method that is talked about is baking configuration values into the application package but is there any way to provide configuration values outside of that? ie are there cli tools to update individual configuration values at runtime?
Are there any recommendations or best practices for managing configuration across different environments (ie production vs development) ? At Oath/VMG is configuration checked into source control or managed outside of that?
Typically all configuration changes are made by deploying an updated application package. As you suggest, this is usually done by a CI/CD setup which builds and deploys the application package from a git repository whenever that changes.
This way it is easy to ensure changes have been reviewed (before merge), track all changes that have been made and roll them back if necessary. It is also easy to verify that the same changes which have been deployed and tested (preferably by automated tests) in a development / test environment are the ones that are deployed to production - because the same application package is deployed through each of those environments in order.
It is however also possible to update files in a deployed application package and create a new session from this, which may be useful if your application package has some huge resources. See https://docs.vespa.ai/documentation/cloudconfig/deploy-rest-api-v2.html#use-case-modify
I'm new to qooxdoo. I'd like to use it for an embedded web interface for an application I'm developing right now.
To keep building my application as easy as possible I'd like to stay away from using the python build scripts after every change if possible. Because the website will only be used once in a while by a single user load times etc. are also not a big concern for me.
I've read about the "build-all" target but could not find a detailed description on how to activate it with the current release. Can someone explain how I can get a complete desktop build of qooxdoo?
You don't have to run generate.py every time you change the code, only every time you reference a new class. During development it's usually relatively infrequent that you have to re-run the generator, compared to how often you will do the edit/save/alt-tab/refresh/test cycle.
But you can do what you're asking during development by using the "source-all" target, eg:
./generate.py source-all
When loading an app from a file:// url this is fine because file:// URLs are very fast, but you can optimise this manually by modifying your config.json to incorporate specific sets of classes.
To do this, in your application's config.json, add (or edit) a job called "source" and add:
"jobs": {
"source": {
"include": [ "qx.ui.*" ]
}
This will cause all of the qx.ui.* classes to be included into the ./generate.py source build of your application; obviously you can fine tune this further.
When it comes to deploying your application, use ./generate.py build because this will produce a minimised, optimised version (with debug code removed etc) which uses only those classes that are required.
If you are still looking for a build version of Qooxdoo, here is my qxSimple project. It includes some examples.
http://adeliz.github.io/qxsimple/
You can also generate your own build version following these steps :
Dowload the latest qooxdoo release
Go in the framework folder
Edit the config.json file
uncomment the //build-all line
run generate.py build-all
I have created a Web Content Management library for use in WebSphere Portal. At the moment I'm using import-wcm-data to import the library, then I need to add some additional propeties to 2-3 files on the server under Resource Environment Providers and then restart particular services so those changes are detected.
Can anyone explain the benefits of using a paa over writing a simple bash (or similar) script to automate this process?
I don't understand if I get any advantages when using paa, or is paa even capable of updating properties files and restarting services?
I have been working intensively with PAA files and I must say that it is a very stable way of deploying a app requirering multiple depl steps and components.
It does need a startup process but is well worth it in a multi server environment.
You can do all the tasks that you can do in a Ant file as well as using the wsadmin script interface. I only update res env settings and the such in WAS and do not touch any props files for that reason since all settings are stored in WAS.
In my experience, a PAA is not a good method if you're merely importing a content library.
I don't think I understand why you are doing the import manually and not syndicating, but even if there's a good reason not to syndicate, the PAA process was too involved and required too many precursor actions (deleting libraries, remove PAA, deploy PAA and then activate the portliest) to be a viable option for something as simple as importing a WCM library.
Since activating the portlets I was importing with the PAA was an extra step, I don't believe you can restart applications either.
I used Sencha 1 in the past and I am going now for Sencha Touch 2... And I am interested in using Sencha Cmd...
So... I did the basic sencha command:
sencha generate app Nameofmyapp path/to/myapp
And when I try to load the website... it takes over 10 seconds to load (and it has no functionalities). I have seen other people having the same issues than me, and I found the most useful answer here (and it solved the problem):
Sencha Touch 2.2.0 loads very slowly. Is it normal?
But it's nonsense... Is it not possible to make it run faster without needed to minify everything? Is there something Sencha cmd does that I should erase because it's too heavy and useless?
Should I not use Sencha cmd?
Well, I think the minification isn't the problem, rather that all components (wether you use them or not) are loaded from separate files. The hundreds of requests take time. When you build your app with sencha app build production all (and only) the required components are concatenated into one big file that loads quite rapidly.
Have a look at the docs at Using Sencha Cmd with Sencha Touch that state
Sencha Cmd automates all optimizations for your application, including the following:
Resolving dependencies required by the application and only including exactly what is used for optimal file size/performance.
Enabling HTML5 application cache via automatic generation of "cache.manifest" and resources checksum.
Minifying all JavaScript and CSS assets.
Storing all JavaScript and CSS assets inside local storage on first load and patching them via delta updates between releases.
As a result, your production build can load instantly on subsequent access and updates on the fly with minimal network transfer.
Edit: There is a way to speed up development by changing sencha-touch.js to sencha-touch-all.js in your app.json file under "js". Next use the Sencha Touch Cmd command sencha app refresh which updates your bootstrap.js file. Now all components are loaded from one single file. You need to change this back before building your app though, otherwise all components will end up in your build even the ones you are not using.