Comments on: Ajax and Leaky Business Logic

By: James Taylor

James Taylor — Wed, 10 May 2006 22:45:03 +0000

Storing of rules in the browser is a big concern for many IT folks. SmartForms for Blaze Advisor is one product, though there may be others, that can address this while still providing a rich rules-driven interaction. The rules in SmartForms are not visible on the client because the rules are compiled into XPath expressions loaded into memory. The users can not view the source. SmartForms does not generate any JavaScript code for a specific form. The output of the Smartforms is a set of XForm pages+ XSL transforms and CSS files. No JavaScript is used for rule enforcement; rather SmartForms uses the XForms constructs and the XPath expressions for validation and rule enforcement. Using this design approach no validation logic is exposed to the client. End users will not be able to see the validation logic because the logic is managed by the form models which reside in the browser memory, The only information that an end user would be able to see are the compiled XPath statements and XForm constructs and the constructs can mask these as well.
http://edmblog.fairisaac.com/weblog/2006/05/business_rules_.html

By: Dietrich Kappe

Dietrich Kappe — Mon, 01 May 2006 21:34:17 +0000

I'm not sure it matters where you draw the line here. The two scenarios are similar enough as to make the decision a practical implementation question. Either you are shipping DOM update commands to the client side engine, or you are shipping data which the client then processes into DOM updates.

Nothing precludes your framework from implementing something like this. For example, the classic MS data grid could be implemented either way.

The real concern is where to draw the line with regard to the business logic. Sadly, the trusted environments where you could use client-side logic usually have the best performance, while untrusted, remote environments usually have the worst.

By: scott

scott — Thu, 27 Apr 2006 19:07:37 +0000

Assuming that one does a good job of keeping business logic on the server, then there are (at least) two approaches to complex browser-based UIs. One would be sending UI update commands to the client (which is what I think you mean when you refer to SGUI) and another approach would involve shipping the post-business logic model data to the server (as JSON or XML) and letting the javascript client be smart about how to deal with it. Obviously, sending UI component update commands to the browser makes the “what” harder to extract for anyone trying to scrape the site. But then again, by passing UI update commands back to the browser, then you’ve introduced a dependency between your server code and your client code which means every change to a client could require a change to the server. Anyway, I’m curious…where would you recommend drawing the line?