I am setting up a new site using angular, mvc and web api. The static content (js, css, images, etc) will be in Site A, the MVC site will be in Site B and the api will be in Site C. These are all separate sites, not virtual directories. I'm trying to use bundling in the MVC site to bundle the js and css files from the static site for use in the MVC site.
I've set up a Virtual Path Provider but when I load the site angular doesn't work and also doesn't throw any errors. I'm assuming that the angular.js file is not being loaded from the bundle because if I include a local javascript file angular works.
Is what I want to do possible? If so, how?
Virtual Path Providers only apply to views, not things like CSS and JS. Unfortunately, there's not really a good way to handle this scenario. The bundler can only act on files within the same project, not those in a separate project. If you want a separate site to handle your static assets, then you pretty much just have to resort to referencing them directly. You can use the Web.config's app settings section to set the base URL for your static site (that way you have just one place to go if you need to change it later and you can do things like run transforms on it to have a different value in production). This also means you're somewhat on your own for bundling and minification. However, you can make your static site an MVC site as well just to get the bundling infrastructure and then use that site to handle bundling. All your bundles should be at the standard location of /Content/[style bundle name].css or /bundles/[script bundle name].js. There's a cache busting string added to the path, but you can somewhat handle that manually.
Related
I'm feeling pretty lost and stupid in the brave new world of "modern" web applications with node.js, module bundlers, task runners, and such.
I have a working Zend Framework (ZF 1) PHP application (which also embeds WordPress multi-site allowing users to create their own blog sites). It is hosted on an Apache server with mod_php. It uses html tables a fair bit for forms and data displays, but thankfully not for entire page layouts, though the css is based on a fixed-width page of 1000px.
The application began development under the notion that javascript should be used only for "progressive enhancement", though eventually we succumbed to requiring that javascript be enabled in order to get correct behavior. We support signup and login using OAuth2 authentication through several providers (Facebook, Google, LinkedIn, Twitter and others), but only via the server flow not the javascript SDKs. We use jQuery and limited amounts of Zend_Dojo javascript libraries plus a handful of homegrown javascript functions (in addition to whatever WordPress uses).
We fairly recently added an Nginx reverse proxy in front of the original Apache webserver. It hosts our ssl certificate and serves static file assets.
Now we're looking to move toward a more responsive design to better accommodate mobile and tablet users, and musing about progressive web apps. So major changes to css and increased use of javascript are in the cards. Although the Nginx serving of static assets gives us eTags, Google Page Speed Insights tells us that we have blocking downloads of javascript and css resources, and that we don't take advantage of browser caching.
It appears from various articles I've seen that the Webpack bundling tool can provide major help in addressing all of these performance bottlenecks. But for the life of me I don't see how it fits in to this ecosystem. My mental model of how our site works is that an http query is analyzed by PHP code, dispatched to a PHP action routine that accesses session data and our MySQL database, and then outputs html via phtml templates (ZF1 view scripts) that contain embedded PHP tags. The phtml templates may contain <script>, <style>, and <img> tags, either directly or by being injected into the html by other PHP functions that manage the overall page layout and the content of its <header> section.
But when I look at Webpack, it seems like it's expecting some sort of top-level javascript file from which it can build a dependency tree of other javascript and css files via import or require directives, or something. And it somehow supports cache-busting by hashing the contents of static asset files, creating new files from them with the hash value embedded in the file name, and editing the references to those files to include the hash value. But for this application, all of the references to javascript, css, and image files appear either in .phtml files (usually within embedded <?php> tags) or in pure .php files. Yet webpack doesn't appear to process php files at all - so I don't see how it can either find the references to javascript, css, and image files, or edit them to include a hash! And the articles I've seen about using webpack in PHP projects don't seem to mention this issue at all. There's an html loader, but not one for PHP. Is there some sort of standard practice about using javascript in an independent modular fashion within PHP sites instead of using <script> tags that I just don't know about?
And finally, different web pages have different requirements for javascript and styles, while webpack seems to want a single javascript main entry point from which all dependencies can be found. Does using webpack in this ecosystem imply making a separate webpack project for each page? I've read lots of articles about webpack, but they all seem to be dealing with web apps that are not structured at all like mine!
I did read this answer here on Stackoverflow which I expected would enlighten me. It came fairly close - it explained that I do need to create a top-level index.js file that requires all of the other javascript files. But since different pages use different javascript, I deduced that I would need to create a different index.js file for each page (and thus treat each page as a different project). Can that be true? Many articles talk about "single page apps", so perhaps that's just the assumption in these kinds of descriptions. Or maybe I need to understand "Code Splitting". Maybe if I keep reading that answer over and over again I'll eventually get the gist. It talks about CSS and style-loader and css-loader, but it's not clear to me how the <style> tags present in my .phtml files get processed by them (not to mention styles enqueued in WordPress code). I've attempted the SurviveJs and Official Webpack documentation, but again, they seem to be talking about a different universe than the one I live in. I'm thinking that a Rosetta stone exists somewhere that would map this new world back to traditional PHP apps! Any pointers?
It's an old question, but I attempt to give some pointers, as I've just went through similar hurdle: trying to integrate Webpack with legacy ZF1 app to do:
Asset bundling
Cache busting via appending version hash to filename
Catering for different bundles for different app routes
My approach:
First I checked in newer versions of Zend_View provide some solutions for versioning front end assets. I found this:
https://docs.zendframework.com/zend-view/helpers/asset/
and really liked the idea of encapsulating versioning concerns in separate config file. Obviously to be able to use this format I either have to use this zend_view helper in legacy app, or simply extend legacy zend_view class and add ->asset method that simply reads in the resource map of this format:
'view_helper_config' => [
'asset' => [
'resource_map' => [
'css/style.css' => 'css/style-3a97ff4ee3.css',
'js/vendor.js' => 'js/vendor-a507086eba.js',
],
],
],
The additional advantage of sticking to this format is that once you'll upgrade your app to newer version of Zend Framework or Zend Expressive, you don't need to change anything, just start using Asset helper of modern Zend_View.
Once we have a map like that we need to make webpack write it. So HtmlWebpackPlugin is not restricted to html files. We can write our own template and have a full control over how templates being written with webpack variables (such as asset name and hash). The big advantage here is that webpack doesn't need to overwrite typically numerous view templates that can turn into a mess and has its own problems (eg. what if we include scripts in controllers via headScript calls?) - it only writes the map. This bit solves the issue #2 - cache busting. Issues #1 and #3 - asset bundling and creating different bundles can now be solved native webpack way - by creating multiple bundles and then writing config file using our custom template:
const path = require('path');
module.exports = {
mode: 'development',
entry: {
'js/vendor.js': './frontend/src/js/vendor.js',
'css/style.css': './frontend/src/css/style.js',
// and so on...
},
output: {
filename: '[name]-[hash].js',
path: path.resolve(__dirname, 'public/js'),
},
plugins: [
new HtmlWebpackPlugin({ // Also generate a test.html
filename: 'view-helper-config.php',
template: 'view-helper-config.tpl'
})
]
};
And the view-helper-config.tpl would be:
'view_helper_config' => [
'asset' => [
'resource_map' => [
<% for (var chunk in htmlWebpackPlugin.files.chunks) { %>
<%chunk%> => <%= htmlWebpackPlugin.files.chunks[chunk].entry %>
<% } %>
],
],
],
I'm using Meteor 1.5, FlowRouter and Blaze.
I've been working on an app which requires offline support, unfortunately it also has several (large) areas of the app that are only available to a small subset of users, to avoid bloating the initial JS download with content most users won't require, I'm using dynamic imports at the FlowRouter.route({action}) level.
For offline mode (in addition to handling the data, etc) I'm using a service worker to cache the JS, CSS and HTML. Unfortunately, because dynamic imports work over the websocket, it isn't possible to cache these as they are loaded.
Fortunately, the user has to notify the server of their intent to work offline (so relevant data and files, videos, etc can be downloaded), this gives the opportunity to load these dynamic imports prior to the client going offline.
What are my options for caching dynamic imports? What I've considered so far:
writing a simple package with all the dynamic imports loaded statically, and with {lazy: true} defined in the package.js.
requires quite a lot of restructuring
the lazy: true means the package isn't actually available via a URL, it seems it is only available as a dynamic import itself.
writing a server side "fetcher" that will take a package name as an argument and serve the content from the file system
I don't know how the client side packages are stored on the server, and if the server has access to those files at all.
using browserify (or something similar) to manually generate a static js bundle in /public which can be downloaded when the client states their intent to go offline
Its very manual, and a change to the dynamic imports could easily be missed.
Has anyone attempted this before, I know meteor doesn't officially support service workers, but as far as I can tell, with the exception of dynamic imports, it plays nice with them
I have a JavaScript web application that we are offering to customers using a SaaS model. Right now, the application consists of several HTML files, JavaScript files, CSS files, and image files as well as a single proxy page (ashx file) with a config file. We have deployed the app on GoDaddy's shared hosting service.
We currently deploy an exact copy of the entire app folder structure for each customer and I am quickly realizing that this is a nightmare in terms of maintenance when I need to provide an update or bug fix. I have to make the change to every instance of the app for every customer.
Is there a better way to handle this? I've heard of using a single code base with multiple config files for dynamic apps built on server-side technologies like ASP.Net or PHP, but I have no clue how I can do this with JavaScript, especially since the HTML pages need to be slightly different for each customer.
I've started using SailsJS for a small web app and so far it's great.
However I'm struggling with the assets and layout.
Basically I would like to be able to use different type of assets (groups of css files) depending on the page.
For this, I wrote 2 different layouts, each should includes the correct css files.
However, when I add those files in the config/assets.js files there all bundled together.
Is there a way to specifiy in my layout which assets i want to use ?
I know you can specify assets.js or assets.styles but I would like to be able to create my own group .
I also tried to put those assets in a different directory (public for example) and load them manually in my layout. It's still not working because the server doesn't want to 'serve' them.
Any idea ?
Glad you're liking Sails :)
For now, you can (a) bring in all styles all the time and make only the relevant ones apply (b) use another tool (like Grunt) to bundle assets like you would in a vanilla node.js project or (c) link the stylesheets manually (put them in your public folder).
As for the roadmap-- the community is working on more options for serving templates/styles/client-side logic. There's an open spec here:
https://github.com/balderdashy/sails/issues/240
Hope that helps!
I know this is old, but in case anyone else comes across this; in recent versions of sails the asset pipeline is built around grunt by default (I haven't used sails before 0.10.x).
You can add your own exports in tasks/pipeline.js and link those to the appropriate location in tasks/config/sails-linker.js. E.g. you could have a views/public folder and tell sails-linker to inject publicCSS vars there. Then adjust your layout.ejs so that it imports the styles/javascript from whichever folder.
I'm currently developing a static site (no backend or server stuff) with Backbone.js and Middleman. The site doesnt have any dynamic content, just plain html code. But it has some transitions between pages and some Javascript effects.
So I want to make use of Backbones Router for the history and want to append the views dynamically to the DOM with Backbone views. So far so good.
Now I was wondering where to store the HTML parts of the site, so that Backbone can use it. With Inline script tags I think it gets too messy, so I want to swap it out in different HTML files. Now I could dynamically load the HTML files via requirejs, but I think it would be better to pack all the HTML stuff in one JS file and load it the first time someone visits the page.
How could something like this be done? Or does anybody have a better solution?
If you are developing a HTML5 application, then you can use application offline cache to fetch all the necessary HTML files and other resources. It involves writing a cache manifest file.
The following website provides a nice description of the offline feature and writing the manifest file: http://diveintohtml5.info/offline.html.
Personally I seperate all the parts of backbone in different folders. So for the templates I put each and one of them in a seperate files in a template folder. That way while developing everything is clean. I load them by using "text!" functionality in require.js.
When I want to put the project in development I use the optimization part of require.js which minifies and combines all the files for me.
Hope that helped.
After a lot of researche, I'm doing it this way:
Store templates as .jst.ejs in template folder
include them with Sprockets
use JST to load the templates
In backbone I use the views class to extend new views and use the templates:
App.Views.Layout.Logo = Backbone.Views.extend({
template: JST['templates/layout/logo'],
el: "#logo",
});