JS Compilation

So you have lots of options,

• YUI,
• Closure,
• UglifyJS.

Since I'm a noob at javascript minification, I've been using the default Sencha CMD yui compressor to minify my scripts. Apparently I think Sencha hacked up the compressor to be Sencha framework aware or something (so claims Sencha themselves).

When I tried using Sencha CMD to compress one of my all-classes.js scripts, it threw some js errors when I deployed.

I then tried to use Google Closure compiler online at http://closure-compiler.appspot.com/home
but it told me my file was too large. I guess I could download closure to run on my local machine, but I didn't feel like learning how to use closure at the moment.

Then I remembered earlier in the morning I crossed the site http://www.freeformatter.com/ which had a butt load of formatters and, whoop dee doo, a js compressor. They said it was also yui based, and had no effect anywhatsoever on your code.

I gave it a shot by linking my url.
Bingo!
No size limitations, no problems, and it worked during deployment. Better yet, it compressed my file just as well as the Sencha one did, so I'm not sure where Sencha went wrong.

In any case, go to http://www.freeformatter.com/javascript-minifier.html#ad-output. It's awesome!

sencha cmd findings

1. Trailing commas are crap. Remove them from your js laziness habits.
2. Do not use Ext.create(myclass) ?! For some reason, it gets angry at me.


3. If for some reason, sencha cmd v3.1.2.342 does not include your controllers when you compile to all-classes (and you happen to go crazy) here is the solution! (which I finally found, after a full day's worth of fiddling about)

http://www.sencha.com/forum/showthread.php?264130-sencha-compile-does-not-resolve-controller-dependencies

Yes, Sencha is trying to screw us all! You have to include which SDK you are using, because apparently sencha cmd works differently for different sdks. Yes, shoot me now, but that's how it works.

So, I'm running the command

sencha -sdk ../../ext compile -classpath=../../ext/src,. page -yui -in index.html -out build/index.html

Horrid!

Ext grid reconfigure function

This is what everyone was dreaming for in terms of reusing their grids!

You can pass in a new store and new column definitions. Awesome!

function: initComponent()

In Extjs, sometimes you want to create a component, and use it immediately after creation.

If you're using Ext.define('app.view.blah', {});
it can be really hard find a way to reference an instance of the class you just created.

It took me forever, but all you do is use the
function: initComponent() when placing items into your view.
Since the scope this of the whole function is an instance of the class, you can use the this keyword at the end of the initComponent function.

Interestingly, there is also an afterrender function

Agh Ext!

http://stackoverflow.com/questions/7316967/extjs-4-problems-with-jsonstore-post-request

Sillyness!

I've had a lot of trouble with xml loading too, and I learned some stuff that I might post later on.

But ewy ew ew

Using @Consumes("x-www-form-urlencoded")

For all the newbies out there (like myself :-)

When you use @Consumes("application/x-www-urlencoding")
you use @FormParams not @QueryParams.

Silly silly!

Tomcat/JAX-RS

I'll have a lot to write about my experience with JEE and creating restful services later.

However, for now, I'd like to talk about the following problem that I've had twice:

After making some changes to the Resource files, I've started to get this response:

exception

javax.servlet.ServletException: Servlet.init() for servlet ServletAdaptor threw exception
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
 org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:879)
 org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:617)
 org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1760)
 java.lang.Thread.run(Thread.java:619)

root cause

java.lang.IllegalArgumentException: java.text.ParseException: End of header
 com.sun.jersey.core.header.MediaTypes.createMediaTypes(MediaTypes.java:224)
 com.sun.jersey.core.header.MediaTypes.createMediaTypes(MediaTypes.java:191)
 com.sun.jersey.server.impl.modelapi.annotation.IntrospectionModeller.addConsumes(IntrospectionModeller.java:152)
 com.sun.jersey.server.impl.modelapi.annotation.IntrospectionModeller.workOutSubResourceMethodsList(IntrospectionModeller.java:338)
 com.sun.jersey.server.impl.modelapi.annotation.IntrospectionModeller.createResource(IntrospectionModeller.java:120)
 com.sun.jersey.server.impl.application.WebApplicationImpl.getAbstractResource(WebApplicationImpl.java:623)
 com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:114)
 com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1013)
 com.sun.jersey.server.impl.application.WebApplicationImpl.access$600(WebApplicationImpl.java:153)
 com.sun.jersey.server.impl.application.WebApplicationImpl$11.f(WebApplicationImpl.java:652)
 com.sun.jersey.server.impl.application.WebApplicationImpl$11.f(WebApplicationImpl.java:649)

What the heck is that? The first time I fixed it by making a new project and redoing everything (!)

The second time, I tried restarting and copying all the Resources files from the old project to the new one. Turns out, it still messes up.

Later, I found that the problem is in the @Produces and @Consumes annotation.

For one of the services, I had written @Produces("x-www-form-urlencoded") instead of @Produces("application/x-www-form-urlencoded)

In conclusion, the root problem 

java.lang.IllegalArgumentException: java.text.ParseException: End of header
is usually a stupid annotation problem.