Austin Kottke's Code Site

Thoughts about Architecture – Java, C/C++, JS, Objective-C, Swift, Groovy, Grails, (RIP Flash)
Archive for the ‘ajax’ Category

I combined Stripes and Velocity into a J2EE filter that came out to be extremely useful, so I could have Stripes/JSPs and have Velocity rendering with every request. I love the toolbox.xml concept of velocity so I couldnt live without it, but wanted to use stripes for its amazing action controller functionality. Here is a filter which modifies the stripes response and then parses the response through the Velocity Template Engine. package; import; import; import; import; import java.util.Collection; import java.util.Iterator; import java.util.Locale; import java.util.Map; import java.util.Set; import java.util.logging.Level; import java.util.logging.Logger; import javax.servlet.Filter; import javax.servlet.FilterChain; import javax.servlet.FilterConfig; import javax.servlet.ServletContext; import javax.servlet.ServletException; import javax.servlet.ServletRequest; import javax.servlet.ServletResponse; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; import; import; import; import; import; import; import; import; import; import org.apache.velocity.VelocityContext; import; import; /******************************************************************************************** * * Our basic filter, all it does is take our WebSessionBean which is a wrapper around * the current session and passes it in the request, so that all jsps and other objects * can access the data, such as the current users shopping cart, his user info, and * other pertinent details to the session for this user. * * In addition to basic session addition, we also take the content and * add in the velocity template engine so the session can be accessed from * velocity, and all content, after stripes is done with it is modified * with velocity. * * We perform the following steps: * ——————————- * *…

I found an awesome video that came out last month from one of the Spring Source engineers on building an entire application in Grails. I think if anything this video shows the true simplicity of grails. It outlines security, ajax, authentication, jdbc, validation and how fast it is to develop with grails. You see how robust and quick to develop a data-base driven twitter clone.

I come from a myriad of development backgrounds, actually started doing C/8086 assembly back in the day. Went into playstation development, and then moved onto flash, qt c++, win 32, java, and ajax. I developed heavily in java for the last few years and stumbled upon rails – couldn’t stand the syntax although I loved the power and the scaffolding. I then discovered grails and man this is like a new world. The power of ruby on rails but in a java-like syntax. The key problems I see in web development are: 1. Properly planning the development project2. Allocating enough time to do the project without shortcutting it3. Implementing the project in the time allotted4. Getting management to work with the clients to properly allocate enough time/money to spend on the lifecycle without shortcutting the features I think projects that are heavily ajax/html or flex projects can be GREATLY simplified by using grails as it writes a lot of the code for you and can really make some of the back-end development which we never want to do a breeze and very integrated. The problem with writing entity beans in java is that the annotations and amount of code written pales in comparison to a grails entity bean and how simple it is to add validation, etc. I plan to do some more examples as I get more and more familiar with the grails code base. Check it out:

So I’ve been doing a lot of java/ajax development recently, and having to compare frameworks was one of the main things I’ve had to do. I used JSF 1.2 actually due to legacy server issues, not 2.0 (which I hear is a lot better) but comparing it with Stripes/Wicket I must say that: 1. JSF has a LOT of issues integrating into existing browsers, 2.0 is probably a bit better but sometimes the pain of having to have ALL tags written for you is VERY troublesome. I recently had to use a rich faces fileupload component and the integration on some browsers has major issues. While it is good to have a very tightly integrated ajax framework it sometimes is painful when trying to integrate in something like the YUI components. 2. Stripes/Wicket are good because they leave a lot of the ajax development to yourself and provide a VERY awesome hands on approach where you can actually write your own code with minimal development time. I find this actually was easier on some other projects. So in a nut shell… Id stick with Stripes/Wicket for a java serverside application as opposed to straight JSF as it is sometimes painful when dealing with all the pre-written javascript components. I guess this brings up a philosophy: 1. A java server side framework should NEVER be so tightly binded to the front-end UI logic WHEN you are depending on browser support. Or provide some alternative to use the latest prototype/ajax libraries. 2. If it is tightly binded,…