In my app, developed using ember-cli, I need also some external resources like bootstrap;
now I'm importing it through the Brocfile:
app.import('bower_components/bootstrap/dist/css/bootstrap.css');
app.import('bower_components/bootstrap/dist/js/bootstrap.js');
Is it possible to use a CDN instead of local file, defining also a callback to local file in case the CDN is offline?
Ember-cli-cdn sounds like a partial solution to the problem to me. Here is a quote from the Readme:
This addon allows to work with local copies of libraries during development, and then automate switching to your CDN version when you deploy your application.
But it doesn't solve the "fallback to local file if CDN is offline" problem. The only pattern I am aware of (also used in ember) is to put the script loading at the end of the html allowing page rendering even if the CDN isn't responding.
Related
I am using Nuxt.js for my web applications but never used the full static generator until now. My CI/CD pipeline builds and deploys a docker image containing of an nginx image with the static generated Nuxt.js app. My problem now is that I can not figure out how to use and load an app configuration file. Of course I could define all environment variables (like API_URL) during the build process but then i would have to separate images for each environment which would be unfortune.
My approach that I have in mind would be creating a config.json file and maybe having nginx deal with that but how can I tell my web application where he should look for the settings file?
My guess is that maybe people using webpack have come around this problem and know how to deal with it.
I have tried to look into this before.
The TLDR is that you cannot have on-runtime variables for the target: static build, especially with the way how some modules are made.
More info on this Github issue: https://github.com/nuxt/nuxt.js/issues/5100
So yeah, it comes down to have some dynamic webpack configs via your CI/CD, this is how my team handles it at least.
I am finding old CSS code on my browser instead it has the new code in server files. I can see the minified CSS code on browser when application gets loaded up.
My team is using Liferay framework which seems to minify the CSS files. I am noob in liferay.
I found portal-ext.properties under liferay-portal-6.1.10-ee-ga1/tomcat-7.0.25/webapps/ROOT/WEB-INF/classes/ but didn't found any parameter for minifying the CSS files?
You shouldn't just update any CSS code you find deployed on the server. Instead, update your theme, build it (it builds to a web application) and deploy it to the server. This will take care of minification and updating caches. Just changing random files in the realm of the webserver will not.
For this you'll have to find the source files for your theme (or a whole plugins-sdk, which might contain that theme). Look at your organization's source control system, which is where I'd expect it.
Explaining how to update and build themes goes well beyond the scope of a single answer here, if these are really your first steps it might be worth getting some help from someone who has some experience with Liferay.
I am configuring grunt for SAPUI5 project. I can configure grunt taks for minify, test and etc. I see there is grunt-ui5 grunt plugin but I am not able to understand what exactly this plugin is doing or useful to SAPUI5 projects.
Thanks
The grunt-openui5 plugin by SAP is documented at github.
It can be used to build UI5 themes and package components and libraries into preload-files.
UI5 tries to load most of the modules of a component or library with a single request from a component-preload.json / library-preload.json file. If it cannot find a preload file, it has to request all modules individually resulting in many many requests and thus poor performance.
grunt-openui5 is used to create these preload files. It also minifies the code while doing so.
The grunt-ui5 plugin is something inofficial which seems to do similar things. You would have to ask the author directly to get more information. I recommend to use the official grunt-openui5 plugin.
For ui5 applications it's not common to use the grunt task for minification , instead we use the grunt-openui5 task. It will create the preload file, which is a json object that contains the whole app.
{
"version":"0.0",
"name":"app name",
"modules":[
"control1": "code for control1",
"control2": "code for control1",
]}
When control1 is required, ui5 just uses the preload to get the code for control1. In this way, ui5 avoids triggering a new request. Anyway, If the preload file is not present, it will have to request control1.js .
If you want to see a real preload file, open any ui5 app and go to the network tab of the browser.
Using the grunt-openui5 plugin for grunt, it will do the work for you, and will give you as a result a library.css, rtl, library-parameters.json (same thing, but for themes) and the preload.json (for the js files).
Instead of using grunt-ui5, I would recommend you to use the the oficial plugin grunt-openui5!
grunt-openui5 is a really amazing grunt plugin created by bunch of SAPUI5 core dev team ;)
It mainly allow you to do 4 things:
create Component-preload.js (optimized and minified version of your app)
create library-preload.js (optimized and minified version of a custom library)
create a custom theme
create a local web server to test your app locally
I've covered it a little bit on my blog post Custom Control 101 if you want to check it out.
I'm using it in daily basis and you can read some of my blog posts about it.
Just a small remark: in the future, consider switching from grunt to gulp, as gulp is newer and faster. For SAPUI5 there are packages with same functionality in gulp, as ingrunt.
I'm using ASP .NET 3.5 and looking a way to bundle a bunch of my scripts. I came across ScriptManager's CompositeScript element. Is it a good way solution to use for bundling? Does it have any ramifications etc?
Pros and Cons, Traps are similar for other script bundling solutions-- you will want to minimize first, pay attention to order of scripts, start your scripts with a ; to close off any unclosed scripts in another file.
One ASP.NET specific issue is the debug/development experience. If you combine your scripts, it is much more difficult to find your code in the IE debugger, the script will have a machine generated name that looks similar to other framework generated scripts & your code will be buried in a much larger file.
So I register my references in code behind and wrap them in ifdef DEBUG/endif and ifdef RELEASE/endif (be sure to define a RELEASE in the project properties, it doesn't happen by default if you use this trick). In the RELEASE version, I bundle all the scripts and the DEBUG version leave the files separate.
Also per Microsoft's recommendation, script bundling works best for files that you need throughout the website. If you have a multipage site with A, B, C and your users normally visit only one of them, then bundling the files for A,B,C will give the user 2 extra files. I think this is a bad micro-optimization because most apps have small javascript files & large libraries, so a website's worth of JS bundled is not enough bytes to worry about, unless you have a lot of traffic.
Finally, the server side ScriptManager doesn't offer any way to defer scripts or dynamically trigger a load from the client side (other than load scripts after UI), I use LAB.js to dynamically load scripts later... this sometimes can allow you to defer a script until you know you need it and possibly defer loading that script forever. Once you bundle that script, it will be loaded for each user if they turn out to need it or not..
Part 2
Another gotcha, at least for me, is that while you can enable caching of JS files in web.config (no time to look up syntax at the moment!) and you can also enable caching at the IIS level using the expires header, the ScriptManager does nothing to help you "bust" the cache when a new version comes out. Ideally, a script management tool would let trick the browser into thinking the script is in a folder that changes as the last update changes, so that scripts could be client side cached for a year.
I wish I had info on if the scripts are server side cached-- I would guess they are not. But because the user gets the script usually once per day at most -- on my server they seem to cache for 24 hours, it isn't too interesting if the scripts are regenerated on each request.
And finally, if you are using a CDN for things like jquery, (depends on if you are public or intranet) it is the 4.0 and 4.5 version that makes it easier to tell the ScriptManager to use a CDN and fallback when the CDN is down.
use sumfile.js?n={0}
where {0} is the number os your building
I searched almost two days for a solution but really i cant untill now, In short I deployed my site to a OVH server with filezilla following the steps in this tutorial here
After deployment I find that my site works fine but without CSS content in FF and Chrome, so when I check in firebug I find all CSS styles are loaded correctly but empty without content,also JS file are loaded with content and all images too.In IE I have the style that works fine but no image is loaded ??I work on Ubuntu and I use a Virtual Machine to use IE...
I almost did everything, I cleared the cache and I changed the access rights of all files, I specify for files => 705, the CSS and JS => 604,finally I put everything to 777 but still no change ...
An idea?
The problem comes from assetic : when css and js files get minified and concatenated using closure or yui css, .. java is called to execute jar code contained in .jar files.
On OVH shared hosting servers you don't have java available, so the output file that symfony generates when you run the assetic dump command is actually empty (hence your empty css + js files).
You should only minify those files (assetic dump) on your local server and then upload the output to your server. Don't run assetic dump on your production server! (well at least with an OVH shared hosting)
I had this problem too, and the culprit turned out to be an outdated version of the PCRE regular expression library that was compiled into the CentOS flavor of PHP. Try to run the command php -i or use the phpinfo() function and check if your version of the PCRE is 7.0 or newer. If it's older, it doesn't support the shorthand version of named capture groups.
To fix this, try to update assetic to a newer version that uses the more compatible longer version of named capture groups. If you can't do this, you can modify the offending file /vendor/assetic/src/Assetic/Filter/BaseCssFilter.php directly. Just replace all occurences of (?<paramname> with (?P<paramname>.
Note that the correct way would be to override this file instead of modifying it directly in the vendors directory.