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).
Related
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 am building a TVOS app in Xcode. I know it is recommended to have following file structure:
client/ (this folder is outside my project folder)
client/templates (tvml files)
client/js (javascript files)
But client/ is not part of my tvosapp.xcodeproj, therefore in XCode, I cannot see the tVML files.
Questions:
How do I include the /templates /js folders in my project to be submitted in XCode?
If I have 2 projects, how can I separate the /templates /js folder for each project if I share the same /client folder?
Check out this https://github.com/toshi0383/TVMLKitchen its something I came across a couple days ago and it works great. It requires a bit of restructure to your current TVOS app as it hijacks the Navigation and focus engine (pretty sure at least). I branched what I was working on and used this and my life is so much easier. No server, all parsed on the client. Extremely fast and a lot of flexibility.
You need not have the exact same specified structure of client from the sample code, to me, as a front-end developer it looks bloated.
Have a look at this sample code that I ported from the original sample code which is using a better structured client setup. Though it uses atvjs framework, you'll get a sense of how to better structure your client application.
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.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.
I am writing a small application at the moment and am trying to organise my build output to be a little closer to the finished product. The application is made up of a number of different projects. There is a core library that contains most of the functionality, a GUI app and a command line app that both reference the Core Dll, and a number of Plugin Dlls that are loaded at runtime and implement different data sources, these all reference core.dll, these also may include some other third party dlls. There are also a number of peripheral files such as a readme. And finally the core.dll and the datasource plugins are unit tested.
I would like to configure my build so that everything is output into directories as I would expect it to be when installed. I want debug and release builds to be built into different directories but otherwise have the same directory structure. I only want tests to be built for debug builds, and want them to be runnable, but seperated (I guess all test dlls would get output into a seperate directory). Here is how I imagine the structure will be.
Code/
solutions etc here
Debug/
Project.Core.dll
Project.Gui.exe
Project.Cli.exe
readme.txt
lib/
ThirdParty1.dll
ThirdParty2.dll
DataSource/
DataSource1.dll
DataSource2.dll
Tests/
Project.Core.Tests.dll
DataSource1.Tests.dll
Release/
same as Debug but without tests.
Is there any way of getting a solution to build like this? I'm beginning to think it will be difficult to build the plugins and the app all from one solution, and probably not even wise, but as they will all be distributed together it would be nice. I am open to using Nant or another build tool if that will make it simpler.
It is possible. Just modify OutputPath tag manually in each .csproj in both Debug and Release file to something like this
<OutputPath>..\$(Configuration)\any_subdirs</OutputPath>
You can disable tests building for Release using Configuration manager.
Modifying each project every time you create a new one is annoying.
Here's the solution:
Locate the real vs project, it'll be somewhere under ("%programfiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates*")
Copy it locally somewhere.
Extract it.
Edit the contents making changes that better suit your project layout style. Make sure you update the project name, the name is what you see when looking for the project in the new project dialogue box. It's xml tag is Name, you'll find it in the {something}.vstemplate file.
Compress the content again. (Note: the contents must NOT be in a sub folder, so /* and NOT /{somefolder}/*).
Place your custom project under ("%USERPROFILE%\Documents\Visual Studio 2010\Templates\ProjectTemplates*").
Add a new project is Visual Studio, selecting your custom one, and enjoy!