What is the difference between using ext-all.js and ext-all-debug.js?
Does changing to ext-all.js from debug.js improve performance?
Can I assume that switching from debug to normal file will not have any other impacts on the application?
Also, can any one suggest what ext-base.js do?
Ext-all is basically the minified verion of the debug one. The gain is that it greatly reduces the files size so that clients have to download less. Ext-base are the core functions of ext. If you only use those you could just include that file instead of the huge complete set in ext-all.
On the ext site there used to be a custom js builder where you would pick just the functions you need and it would create a custom js for you with just those modules
Ext-all-debug is provided so that you can debug through the extjs code. It performs extactly the same operations that ext-all.js does. Using ext-all.js will improve performance since the size of the file is much smaller, hence clients can download and access them faster.
Same is the case with ext-base-debug and ext-base.js. These contain the operations on which ext-all.js depends on, for example Ajax operations. Interchanging these files will not have any effect on your application.
Use the ext-all-debug and ext-base-debug during development. Switch to ext-all.js and ext-base.js when in production.
THIS INFORMATION HAS CHANGED FOR THOSE USING ExtJS4.1.
After implementing and optimizing an application, I like many, was confused with which process was optimal for 'production implementation'.
This most current documentation for this turned out to be this document on Sencha:
http://docs.sencha.com/ext-js/4-1/#!/guide/getting_started
It was difficult to identify, but the key for me was step #3. Deploying Application.
For which these four steps are conducted:
cd to root
sencha create jsb - this creates a manifest of classes used.
- it can also be modified prior to build, in case it is needed.
sencha build - creates two files(all-classes.js, app-all.js)
- all-classes.js is non min for review.
- app-all.js is the production ready file
Setup for prod - these are the remaining includes needed in your production file:
ext-all.css //minified-css, concatenated and dusted is optimal.
ext/ext.js //non-debug
app-all.js //minified, concatenated, app + framework files (only classes used).
Hope this helps someone. : )
differences between "ext.js" and "ext-debug.js" are:
"ext-debug" is not compressed (or "minified").
"ext-debug" is not run through the Cmd optimizer.
These files otherwise contain exactly the same code. Further, both flavors download required classes from the "src" folder. In short, both of these files are intended to support debugging.
In order to improve the performance,To reduce the downloads to as few files as possible you can use Sencha Cmd. some thing like this
sencha fs minify -yui -from=ext-debug.js -to=ext.js
For Cmd topics ext 4.2.2 doc set is the more current and you can access the dec here
hope this may help you.
Related
I am writing a documentation for a project that involves multiple developers. We use Subversion (SVN) to work on our code base.
I wrote the first draft of the documentation document using HelpNDoc, which I like for the nice tree-view and easy of use; the problem is that there is a single file, so I don't know how to use SVN to allow other developers to contribute to the documentation and update it.
Do you know if it's possible? If not, can you advice a nice software, easy to use, with a tree-view of the documentation that can be used with SVN or makes it possible for multiple users to update it? We use Windows.
HelpNDoc projects are binary files based on the SQLite open source database engine. The advantage is that the whole documentation stored in a single file so it can easily be copied, moved, shared, backed-up...
However one drawback is that it has to be checked-in as binary content in any version control system including Subversion: diff and merge are not possible on those files.
One possible solution would be to use external documents in HelpNDoc's library: each user works on her own document (which can be a Word document, and HTML web-page...) and a master HelpNDoc project is created to include those documents at generation time. See "Include a file at generation time" in the following step by step guide: How to add an item to the library
Amount of files doesn't matter, real format (text/* or binary) - does. If SVN|any VCS can merge two HelpNDoc files with diverged history (just try it by hand), you'll be happy
I once used Helpinator for software documentation, it's pretty close to HelpnDoc but it's storage format is more suitable for version control.
Fine uploader is 400kb of javascript code and 140kb minified. Since I am not using the UI and only using the API, I would like to build the library without the integrated interface (and hopefully get a smaller lib consequently). Is this possible?
Could not find this in the downloads section.
I've also setup the build environment and built the package myself, but all the files in the _dist dir seem to be bundled with the UI.
Fine Uploader is only 40 kB gzipped, which is compression that pretty much every web server already utilizes. The build is not currently setup to create a bundle without the UI. If you'd like to create such a build, the modules.js file will need to be modified. One place to start would be with a copy of the fuTraditional module sans the #fuSrcUi module. Then, a corresponding entry would need to be added to the concat.js build file. This doesn't seem worth it to save a few kB in my humble opinion, but it's all very possible.
If you're interested in a much more modular upload library where almost every feature is represented as an optional standalone module, take a look at Modern Uploader, which I am slowly developing as time allows. Feel free to open up issues in the repo if you have any questions regarding the future of that product.
I'm working on existing (not mine) Maven project which generates pretty big .war file ~37MB. More than 20MB is made of ExtJs 4.1 files (.js and .css).
I'm not sure which files are really required and which can be removed. I found out that I can remove unnecessary files with Sencha CMD but I'm not sure if it is compatibile with ExtJs 4.1. However, I tried to run it, but it always says Command must be run from an app or package folder.
Here is structure of my project: http://prntscr.com/4o97zy
Any help is apperciated!
In production you can just ext-all.* and remove rest of them which reduces size application size by 10MB. Here is the bare minimum structure that you can have in production. If you use any additional plugins include them as well. I would suggest to keep ext-all-debug.js/css as well, use maven profiles to take care of copying ext-all.* or ext-all-debug*.
The above structure is of size 2.5MB, more or less that will almost be sufficient. You can miniify these files and put it into your war. There are multiple ways of doing it. You can use ycompressor to compress and put it in your webapp or from server side you can compress files whenever user requests(Google-web utilities).
I have created three different solutions for three different clients, but those solutions are for an app that have the same features, classes, methods, resolution, except for the images, XML resource files, and a web service reference, that are specific for each one.
I would like to have just one solution for all those apps, that I could open in VS2010 IDE for edition, without errors. So, when I need to build or publish an specific app, I just set the client which one I need to, and go ahead to building or publishing.
It is important to consider that XML file names will be the same, as classes and images names too. The difference will be the content, but the name will always be the same.
My intention is to reduce my effort to maintain many solutions, having just one solution to work with.
In my company, we will have more than those three clients soon, so I am worried about how to maintain that. The best way will be have just one solution and when I need to generate a new app for a new client, I have just to change/include a few things (like some resources and images) and compile to a new client folder.
Is it possible? If so how?
One option would be to have a master solution which had the following
A "Template" project that contained your actual application and all of the shared code
Projects for all of your clients
In the projects for your clients, you could have links to the files in your files that come from your shared project. Then, in each of those projects, you could add the files that are only specific to them.
With this kind of structure, whenever you made a change to your Template project, all of the client projects would be updated as well because they just have pointers back to the Template project.
A good reference for this kind of setup would be the Json.Net Code Base. There he has a solution and project for all of the different configurations, but they all share the same files.
In terms of ensuring that the xml files are named properly, you might just want to put some checks into your main application to ensure that it has all of the files needed or potentially add a check into your build process.
There are many ways you could look to tackle this.
My favorite would be to run some sort of pre-build step - probably outside of Visual Studio - which simply replaces the files with the correct ones before you do a build. This would be easy to automate and easy to scale.
If you are going to be building for many more than three customers, then I think you should look to switch from Visual Studio building to some other automated build system - e.g. MSBuild from the command line or from something like TeamCity or CruiseControl. You'll find it much easier to scale if your build is automated (and robust)
If you don't like the file idea, then there are plenty of other things you could try:
You could try doing a similar step to above, but could do it inside VS using a pre-Build step.
You could use Conditional nodes within the .csproj file to switch files via a project configuration
You could look to shift the client-specific resources into another assembly - and then use GetResourceStream (or similar) at runtime to extract the resources.
But none of these feel as nice to me!
I have many bundles (let's say hundreds) and it is quite difficult to specify relation between bundles+features-distrubutions in UI. Image, at first I define all relations between bundles, features and distribution. Than I want to update some bundles... it is almost impossible to find them in current implementation of UI. They are not groupped and one list of all bundles without any search bar is really hard to work with.
Is there any support for a file based solution. For example Apache ACE would watch a certain folder containing distribnution's bundles. When ever I make a change there, it would be propagate it to all targets.
There is currently no file based solution that matches what you describe, however, I think there are still a couple of solutions that might help you:
There are two types of associations between artifacts and features in ACE: static and dynamic ones. The latter can be of help to you, as they always automatically bind to the highest version of a bundle. So, once you've made all your associations, you can simply upload a set of newer bundles and the associations will adapt.
There is also a REST API you can use to programmatically talk to ACE. You can use that to further automate your process.
That said, you have a valid point that it is difficult to keep an overview when there are a lot of artifacts in the first column. I would advise you to watch, or even contribute to the following issues that were all created to improve this situation:
https://issues.apache.org/jira/browse/ACE-319
https://issues.apache.org/jira/browse/ACE-320
https://issues.apache.org/jira/browse/ACE-321