This is something I’ve been thinking about a lot. What are the advantages and disadvantages of a design where the pages are un-mapped pure HTML and JavaScript and the data is all JSON pulled from the Struts 2? No action mappings means relative page references so we don’t have much use for the Struts 2 URL tags or any other tags for that matter. Literally ANY information we need from the model can be retrieved through JSON or handled with a custom Interceptor. Session management for example is usually dealt with in an Interceptor anyways. I’m assuming that JavaScript can get information from the headers here which may not be correct. Please let me know if I’m wrong. Even if I am wrong, one might still use a hidden control or some other means to stash this type of information in. Regardless, I feel certain that it can be done although I am fuzzy on the specifics.
In a nutshell the end result would seem to be a pure HTML / JQuery UI which a UI-only developer, an expert on page design and usability can work with without ever needing to know Java. A person who’s sole purpose is to manage the user experience from the UI side. With the use of tabs, menus pop-ups etc., pages might never need anything except JSON data which would enhance browser caching. This idea also greatly reduces the need for Web Services, since you already have a cleanly de-coupled model and view. We won’t need OGNL or JSTL or have to mess with the value stack or type converters. If you are using Hibernate, I’ve already seen libraries out there that will convert Hibernate entities directly to JSON.
Am I completely off my rocker here? Is it possible to get what Servlets and JSP promised without all the cruft?
I’m not sure what your final sentence means at all. Not sure what you mean by “reducing the need for web services”, because what you describe are web services returning JSON.
That aside; of course you can do everything client-side via JavaScript and get only JSON from S2. If your client-side framework supports it, I don’t really think there are any drawbacks, as long as your app doesn’t require data-specific bookmarking or you’re using a JS library that supports it.
The level of caching may be slightly higher, but a well-designed, non-JSON-only app can do quite a bit of caching anyway, so I’m not sure how much of a boost you’d get from that–but certainly some.
Depending on the browser you may run into a variety of issues regarding memory usage, leaks, etc. which can be difficult (or impossible) to track down or resolve, but depending on your app’s usage patterns, and your user’s browser preferences, this may never become an issue.
With modern browsers, and modern client-side JS frameworks, this kind of app is completely possible, and is being done more and more–it’s not a unique idea.