Panasonic Youth rob sanheim writes about software, business, ruby, music, stuff and things

calling your data layer via Ajax (jsquery) - a bad idea?

Saw on ajaxian a blurb about jsquery. It is basically a library to grab data directly from your server side JDBC/ORM layer and expose it to your pages as a javascript array that follows the ResultSet interface.

I’m not sure of the wisdom of doing something like this. This directly couples your view layer code to your data layer code. Even if you just want a “quick and dirty” solution and don’t care too much about MVC, I would rather write my JDBC calls in a seperate data layer and test that independantly, and then remote the model objects via DWR. If you really want to be dirty you could just return your dom structure or XML from your servlet and not worry about any “true” model objects. But why deal with the result set interface on the javascript side? If you go with jsquery, where do you clean or strip your data? How do you reuse that JDBC/ORM call in other places without violating DRY? Maybe I’m missing something here…enlighten me.

Never allow a web page to generate SQL calls into your database. That is just too insecure as you could run update and delete statements that way. Allowing any query is worse than SQL Inject Attacks. At least pass it through a call to a stored procedure to limit what can be done with the database and deny access to SELECT, INSERT, UPDATE and DELETE for the web user. I think the best route would be to have the Javascript call a lightweight web service which returns the result as an XML feed, but XML markup can be a bit wordy. If it is a lot of data you could place the results in a CDATA block and use a CSV format and parse it with Javascript. But if you are returning that much data maybe breaking it up into 20 rows per request would be more performant.

It’s obvious that neither of you have even examined the code. jsquery DOES NOT allow client side javacode to make SQL statement calls.

The data query is completely generated and managed by a server side controller.

There is a full working live SQL example at http://www.jsquery.com/ with a full souce distribution included. If you can find a way to break the controllers security model be my guest to try.

For the record:

jsquery does not circumvent a good MVC model in anyway. The ResultSet can be completely managed by the controller which is what the example code demonstrates. The ResultSet is merely a well defined 2D data delivery pattern that is universally understood. jsquery leverages existing API’s which is a good thing and dramatically shortens the learning curve.

In production we use jsquery with an OR Mapper for the model and a full controller using POJO (I’m not big on overblown architectures that add bloated unnecessary layers of code to an application).

The other thing to note:

jsquery is VERY FAST and VERY LIGHTWEIGHT

Much faster than a great deal of the piggy XML based solutions that are out there.

jsquery allows you to add AJAX functionality to your web applications without learning a new API and adopting gigantic new proprietary paradigms.

David:

First off, thanks for the in depth response.

I can’t speak for Brennan but I did look at the examples. The sql example looked a bit strange, as it was doing data access from the jsp but I’m guessing that was just for example purposes. Also, I realize the javascript piece isn’t maing the actual data call - my point was it seems you directly coupling your view code to the data model, or at least the sql statement you are running to generate your result set.

I’m all for simple solutions to simple problems, I guess I just don’t see how this is really much simpler then, say, having a ajax servlet get some data and send the data to the view as a plain list or html fragment or whatever. IMO the resultSet interface is not exactly the nicest api to work with, so I’m not sure why you’d want to emulate it in javascript.

Maybe I’ll give jsquery a try sometime and see how it actually feels in practice.

Rob,

Here’s a break down an MVC break down of the example posted at:

http://www.jsquery.com/java-jsquery/examples/sql/

Model -> zip.sql
View -> zipform.jsp
Controller -> getzip.jsp

the view (zipform.jsp) does request data, just like any other MVC app. In this case it’s getting it from a controller (getzip.jsp) that is accessing the model (zip.sql) and handing off the results bak to the view.

Normally your controller would not be a JSP, it made sense in this case as I wanted to keep the demonstration simple and easy to understand. Lack of simplicity has been the downfall of a great deal of the AJAX and MVC architectures out there.

In this case the results are a single row. The zip,city,state and county that matches the data query made by the controller.

In other cases a view needs to work with a set of data, at some point the view is going to iterate through that set. Whether you hide it in a control in the view, expand it statically eventually you are going to loop.

jsquery implements an interface that returns a typed matrix of data. ResultSet was the best known interface to do this. You can move forward and backward through the elements, get the elements by name, and check the elements data type.

The end result is that jsquery implements a very fast and robust AJAX style data transfer layer in less than 6k of client side code. If we compress the javascript it goes down to under 4k of code to add AJAX functionality.

I was surprised when I read the posts here, as I’ve received a great deal of comments from other developers that have added AJAX to their existing projects using jsquery in under 5 minutes!

I’ve built a chat application with the engine, a calendar application that shows real-time multi-user updates, and added numerous event driven data lookups and displays that all run quicker than the vast majority of other AJAX solutions out there.

All this in about 5k of code on the client which is smaller than most jpegs.

I have to agree with Rob. I don’t understand why the data layer needs to be exposed to AJAX? DWR does the same thing by allowing Hibernate beans to be exposed and it just seems like a bad idea to me.

John,

The data layer is not exposed to AJAX. jsquery is a fast and efficient tool for delivering a controller managed dataset to a browser based client side view. The dataset that is generated/delivered by the controller is represented as a ResultSet for the following reasons:

* Universally understood data representation
* Handles naming and typing
* No new API’s to learn (DRY)

jsquery is also smaller and faster than DRM. Plain and simple. One of the primary reasons is that it is not generating JS representations of objects. The controller delivers the data in a standard data format (the ResultSet) requiring less class specific programming on the client side.

jsquery does not have the overhead of having to generated object representations on the client side. I have never understood why this is such a great idea it seems like real overkill to me.

Also, you don’t need to have a server side representation of the object in order to deliver data. You can use jsquery to deliver data sets from non-OOP data soruces (like a SQL query under the management of a controller).

Hi

I need help on using JSQuery. I think its a great intuitive tool, especially for some of us that are not hard core programmers.

Regards

Brian