Data-centric architecture and design

JSP is a great 'scripting' language for quickly creating versatile views in semi-Java code. However, I do recognise a couple of challenges with JSP. Eclipse helps with a parser/lexer a great deal, but still it does not prevent problems in the following areas:

- Loss of compile-time checks on method gets and sets. It would be ideal if the template would pre-generate Java code, so that I wouldn't lose much time with silly mistakes. Beans are simply not that great for this and time is lost due to loss of compile-time checks.
- Unclear which objects are available for use. The feeling of which API's can be used inside a big blob of text without abstract objects or interfaces is a bit challenging.
- The variety of tag-libs available and how the tags, attributes etc. always seem to be wrong or incompatible.

I've been thinking as well that web applications seem to be written from the perspective of functionality, *what* you want to do with the data, not written from the perspective of the data itself and then wrapping the right functionalities around that. Isn't this exactly the inverted world?

I'm working on a new research framework where data exists at the heart of the system and everything else revolves around that. It does use certain patterns in development, like Front Controller etc. and I do use reflection and beans, but the main attempt is to shield developers from having to declare "field X" in the code somewhere, which always at some point seems to map incorrectly.

This model revolves around the "DataObject" java code. I intend to use XDoclet to auto-generate certain chosen functionalities and go back to standard Java classes. Also, I intend to bind this to Hibernate for persistence. The idea is then that every object will have certain 'functions' associated with it. These are more or less generic ( view/edit/add/delete ). By choosing which functions you want for that object, you could theoretically auto-generate the code that we know have to write by hand. Sounds interesting so far?

One of the reasons of using JSP is that it makes you very versatile in choosing layout. Reasons why 'standard visualization' components fail is because they are not flexible enough. My intention is to merge data objects with HTML template snippets and XML attribute settings for specific types. The output is a Java class that becomes part of the compilation cycle. This class exists in a pre-determined package, chosen in the declaration of the Java object. Since generating HTML with snippets for the page as a whole becomes too complex, I intend to use AJAX to only update one particular division on the page, much like some kind of "portlet" approach.

Now, through Hibernate, it becomes very easy to 'load' objects, even if the framework has no knowledge about what that object truly is. By declaring a data object in a configuration rather than the connected objects like forms or actions ( forms and actions can be auto-generated ), it gains the benefit that the framework can find or populate the object based on reflection/description in Hibernate and pass it to a business rule system.

The effective idea is to take out all ~housekeeping~ code from your web application. You'd basically create a couple of HTML snippets that dictate how your layout looks for the majority of your 'data'. Then you'd typically create a dashboard or portal front-end, where you place your various applications ( nothing stops you from using AJAX to 'replace' apps where you see fit ). Then the framework automatically generates links on pages for common actions based on your template ( using some 'decorator' classes for instance, this can be coded further ). Attach a property XML file with default settings and possible overrides for "CLASS" or whatever attributes and the framework is almost ready.

Since it is already possible to construct any object that the framework not yet knows about, validation is easier. The validation component can accept the object of already the proper type. ( Type checking must already conform, so why validate on that? ). Then pass the object to the validator, which does certain checks on length, etc. The validator returns true if ok, false if not. If ok, then the business rule executes.
( Does the user have access to this functionality? Related to object A, does this setting make sense? etc. ). If that passes, the object is automatically committed. The rule knows from itself what the action is on the object.

In the future I intend to add some wizards, so that it becomes even easier to have a particular page flow.

So, data-centric architecture is what I'd like to call where data is defined and actions revolving around operating on that data are already well-known. Why re-write that code constantly? The only thing one needs to do is call certain business rule logic, some validation logic and some view logic that is auto-generated. The win with having Java classes back is that property getters and setters are verified at compile-time, plus hopefully a bit of a speed-up ( not that it is needed ) in order to generate the pages. Using "Spring", it should become a real fun-fair getting this framework going ( choosing the implementation rule to execute based on other configurations for customisation purposes, etc. ).