ExtJS starting point with Sencha Cmd

Dude this thing does all that work for us …

ExtJS Early starts

When I started with ExtJS several years from now, I worked on a project that included the library in standard script src manner.

I can’t recall that in the time Sencha came up with Sencha Cmd so it seemed completely okay to do so. The project worked out, everyone was happy. I later noticed that lots of folks out there still do this, and I wont argue whether this is a good practice or not, but I started to avoid it as soon I’ve learned the better way.

For a long time (as lazy as one developer can be), I refused to use any external or ready made command line tools for front-end development, as they seemed like another step that will just slow down the process and waste my time. So I didn’t use Sencha Cmd. My colleague and co-author on this blog – Goran, started using it and came up with words – Dude this thing does all that work for us.

As soon I learned about Sencha Cmd and benefits of using it, I started hacking it’s possibilities and it delivered complete happiness to my life. It’s really robust tool that makes your work easier and development cycle looked fulfilled for the first time. Before that we used bunch of various handmade scripts for tasks like minification, deployment, etc. And those scripts were so loosely coupled that you had to look everywhere if something goes wrong. Lots of people worked on those, so you had to go after them in order to find out what exactly this thing does. It was boring, time consuming and generally blocking.

All that washed out as soon we migrated from that chaotic point to the enterprise workflow as people at Sencha described it as best practice for their products – Sencha Cmd.

Start using Sencha Cmd

First thing that you should do when starting with Sencha’s products is to download and start using this tool. Sencha Cmd will automate your routine tasks like creating new project and deployment.

I won’t explain installation process since it’s no-brainer/wizard/next/next/ok. Just one note: If you’re running linux, don’t use sudo, install it as current user.

Workspace

If we assume that you installed Sencha Cmd, we can also assume that you’ll need something called Sencha workspace in order to put things you code together. No, it’s not another package needed to be installed, rather it’s environment where your application(s) live. Whether it’s an ExtJS, Sencha touch, (mobile or desktop app) or whatever, workspace is their home. Also, workspace make itself a good home because Sencha Cmd knows everything about it, maintain it and takes good care of it. Once you decide to start your glorious project that should cover all aforementioned technologies, you’re type something like this:

From now on, your workspace is alive. It’s time to generate some fancy app.

Generating an app

People at Sencha really made this so easy to generate initial ExtJS project that it sums up in one line:

Assuming that ext-5.1.1/ is path to your earlier-downloaded-extjs-5.1.1 libraries, the rest will do as it’s written, generate app called MyGloriousApp in workspace/MyGloriousApp.

N.B. If you’re using something else than ExtJS, for example Sencha Touch, you’ll replace ext-5.1.1/ with the directory of your Sencha Touch libraries.

Ok, now you can open your favorite file explorer or use command line tools to see what has been created. In short, sencha generate app created small and simple app that’ll serve for beginners / in beginning of any (large scale) project.

In order to see what it look’s like, we’ll have to configure our web server.

Web server configuration

Of course, Sencha Cmd comes with server of it’s own:

It will serve your content on http://localhost:1841, and that’s good thing if you’re doing front-end development without thinking about back-end, or you server HTML only without PHP, .Net or any other technologies that are ran on server (Node.js doesn’t count). So in this article I’ll cover basic configuration for Apache web server. Note that this configuration won’t be out-of-the-box or ideal, so in serious production you’ll have to think it out by yourself.

Basic Apache configuration

Since Sencha web server isn’t good enough for us, we’ll configure one Apache server that will hopefully do.

N.B. I’ll try to make this generic for all Linuxes but this configuration may vary from distribution to distribution. Windows users, you’re on your own, google wamp if you’re about to run PHP or how to configure Apache on Windows, if you need Apache.

To tell Apache where your Sencha app is, you’ll need to create new mygloriousapp.ext.conf file for our app in (usually) /etc/apache/vhosts.d/, something like this:

N.B. Note that /srv/www in DocumentRoot, ErrorLog and CustomLog entries will for sure vary in various distros, for example, if you use Ubuntu with default configuration you’ll change this to /var/www/mygloriousapp.ext/…

Next thing to do, is to go and create those directories mentioned in our .conf file, namely /srv/www/mygloriousapp.ext/ and from there /logs directory. It’s where we’ll keep error log (for our application server) and access log that’ll tell us common things about http access to our glorious app.

If you’re asking why we haven’t created htdocs/ directory, the answer lays in simple conformity. We’ll make symbolic link to our project directory stored elsewhere:

Don’t mind the short form. Basically, we linked htdocs to production variant of our glorious app’s output of sencha app build process that comes up next.

Sencha app build

There are generally three variants of build process that you’re going to use in building ExtJS applications. Those are production, testing and development. Their names are self-explanatory in use. In practice they differ in levels of automation applied to your code, in example production variant bundles and minifies your code into single file (although several single files if you count css), testing bundles your code, but doesn’t do minification for testing sakes (i.e. you can debug and actually see your code, not minified dump), and development variant that does neither.

Most of your time you’ll use development variant when you need ready-built app. The thing different in development variant is that boostrap.js (the core ExtJS file generated in your project), doesn’t point to bundled editions, rather on project files one-by-one itself. In that way making it possible to run your code without specifying build process. This is good thing for development, while it’s bad in production where you want to reduce loading times.

Oh, I almost forgot – there is also a handy thing called app watch:

Sencha app watch will monitor changes across your project’s files. If there are major changes (adding new controllers, doing theme changes, etc.) it’ll automatically recreate bootstrap so you will not have to bother with build process. Keep sencha app watch for development only.

Conclusion

As I stated in the beginning, the practice of ExtJS differ from what front-end devs have used to do. Including ExtJS’s compressed library into HTML will work, but it will cost a lots of pain to make it work as it should, and after all that wasted time it wont work as expected. To make a difference, any ExtJS app should be an enterprise ready (fully qualified modern app, if I may call it). People at Sencha really worked this out good, so it can be easily explained in this or similar blog post.

This post should guide you on the way of streamlining your development from building workspace to running builds on Apache server. I hope you’ll find this helpful.