Still not clear with this. I am testing with simple login form (Version is 2.2.1 and no external CSS or JS). After looking up the resource consuming, I am confused with js should i prefer either (sencha-touch.js or sencha-touch-all.js) for development and production. By default the microloader maps to sencha-touch.js. Should i change it?
sencha-touch.js -->
sencha-touch-all.js -->
Here it just give only 29 hits to server but downloading 4 mb of file which is larger than sencha-touch
sencha-touch.js will be making a request to individual source files for each component your app requires in. sencha-toucha-all.js includes all components by default.
See this guide in the docs for more info:
http://docs.sencha.com/touch/2.3.0/#!/guide/building
More specifically, this is what you should be doing:
- use sencha-touch.js in development
- have each of your files require in all the sencha touch components/proxies etc it needs
- when you want to go to production, use the sencha app build command in your terminal to build to a single, minified javascript file which then contains all your code and all the sencha touch code your app needs.
Related
Hi I received a web project with all already implemented CSS js HTML code, directories, project structure etc.
I have to make changes in view.js but I don’t always have internet access on the move so is there a way to continue this project locally without changing my project structure?
I already have an existing web project whose file contains
-an HTML page
-a CSS file
-a js file
Place in their folders respectively
I want to use view.js on this project
The problem I don’t always have internet access when I’m on the move.
So how do I use seen?
Knowing that:
CDN is a script placed in HTML requiring a connection to run view
-Vue CLI is a package that allows to generate a new project view "certainly out of competition"
But I should start over
Because the directory structure and already predefined what doesn’t suit me.
How does it work?
How to just add view and continue the project without zero spread?
I already installed node.js (npm) on my pc if its can help .
"-- IN BRIEF:
If you still don’t understand
Imagine being entrusted with a web project all made HTML CSS JS already configure etc...
And you must use VUE to make changes
knowing that on the move you don’t always have the connection
How do you do that?
Assuming (I can't tell 100% from your description) that it is an un-compiled implementation that uses the CDN, you can easily handle this by copying the vue library locally and update the html to use the local version instead of the CDN.
if you need to keep the html, you could use a browser plugin like requestly but there are many others. There you can select the url that goes to the cdn and replace it with the local one.
Another option for chromium-based browsers is to use local overrides. Picture upload is not working currently, so can't include a picture, but the option is available through the sources tab in the developer tools. You need to enable overrides, select a folder, then you can select the resource that you want to serve from local override.
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.
In Sitefinity WebForms you have a ResourceLinks control allowing you to combine multiple, but what do you use in MVC layouts?
I'm not sure if the razor helper #Html.StyleSheet will do the job?
Adding all the CSS files to the Global folder in App_Data\Sitefinity\WebsiteTemplates[template_folder]\App_Themes[theme] will automatically add them to the site, but won't combine them.
We're working with Sitefinity 8.x and looking for a definitive way to compress and combine JS and CSS, but the pickings seem slim.
With the move from webforms to mvc, Sitefinity didn't include specifically introduce a new bundler or something so you're left with essentially 2 default options, but they've seemed to have opted for approach #3.
1) Use .less and .sass to pre-process as part of your build process.
So in your theme folder you would have a global.less (or scss or sass) that essentially combines them using the #import directive.
Install a VisualStudio extension like Mad's Kristensen Bundler and Minification VS Extension (previously part of WebEssentials) and then define in the VS settings that it should compile and minify on build.
Then every time you build or publish, your one bundled-and-compressed .min.css will be available for Sitefinity.
2) Second option would be to use default ASP.NET Web Optimization.
Where you define static bundles in VisualStudio and then use these bundles by means of #Styles.Render or #Scripts.Render to output them.
3) Lastly a new way has been added with the new Feather approach, which uses the current fashionable approach of Grunt to bundle and optimize your styles and scripts.
In the /ResourcePackages folder you'll already see a gruntfile.js file which has a task you can run which can then compile (and can be extended to prefix, bundle, minify, etc) your .sass into a .min.css which you can then add to your solution.
A sample can be seen here (https://github.com/Sitefinity/feather-packages/blob/master/Bootstrap/gruntfile.js)
I'd use a combination of the above approach to receive the maximum result with Sitefinity where you use option 1 to have VS build out your core/base CSS and JS and then include them using Web.Optimization.
Any additional page or widget related styles or JS can then be included afterwards manually through the css widget which gets compiled through option number 3.
Once you get more familiar with this new approach you can create and load optimized .css and .js on demand - even using a RequireJS approach to load them depended on the widget dragged and dropped on the page. RequireJS might seem out-dated given the latest gadgets and gizmo's but with v9.0 its still being used by Sitefinity itself to add inline-editing functionality.
Let me know if you need more info on option 3, I'm happy to extend my answer with some code snippets, or sample scripts on how I've tailored them.
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 am working with sencha touch 2 in MVC format. I have created a cache.manifest file to bring my app offline.
CACHE MANIFEST
index.html
app.js
guide.css
app/model/Contact.js
app/model/Injury.js
app/view/IncidentForm.js
app/view/Home.js
app/view/DivisionSelect.js
app/view/InjuryResponse.js
app/view/EmergencyContact.js
app/controller/Core.js
i/amcor-app-bg#2.png
i/amcor-bg-logo#2.png
i/amcor-logo.png
i/amcor-tb-logo2x.png
i/arrow_right.png
i/ec-icon#2.png
i/home_icon.png
i/in-icon#2.png
i/ir-icon2x.png
i/ir-icon#2.png
i/ir-toolbar-bg2x.png
st2/builds/sencha-touch-all-compat.js
st2/resources/css/sencha-touch.css
NETWORK:
*
My issue is that the cache.manifest file does not seem to recognize any of my js files except for app.js. When I am working online it seems to cache properly but when I go offline the cache only returns index.html, app.js, and the sencha files. Can the cache.manifest file only have one .js file?
You should really try to use the tools SDK then you don't have to worry at all.
The Microloader helps keep things up to date.
Its a bit light on its error checking output and you must conform to the MVC app layout created by the SDK tools but once its running "it just works".
If the "compile" hangs its probably a missing ref.