AribaWeb: The framework of my dreams?

Could AribaWeb, finally be the framework of my dreams? that for which I have longed for ever since I stopped using WebObjects? The one to finally demonstrate those Ruby guys that what makes Ruby so great is Rails, and what made Java inferior (until before AribaWeb) was its framework, but not the language itself?

So far, it seems that, while not perfect (no client side caching, some Hibernate inherited validation limitations), AribaWeb gets many basics concept right (like programmatic navigation, UI meta generation, runtime UI customization, MVC separation…)

I am simply amazed….

Now someone just needs to integrate AribaWeb with Capuccino, and total world domination would be in their hands.

Functionally Complete Crud Generator

In my previous post I wrote about the Irreducible Complexity Model ….now why is that model so important?

Well, for a Crud Generator to be functionally complete it has to fulfill the following requirements:

1. Be able to generated the Crud Screens for the Irreducible Complexity Model
2. It should be possible to “capture” the entire “model graph” as a single transaction starting from any node in the graph
3. It should be possible to “skip” validation until the “save” button of the screen to save the node where we started is clicked, and, it should be easy to go from there to any of the screens used to edit the other nodes to fix any validation error.
4. It should be possible to search for instances (rows?) of the entity (class, table?) by using a “query by example” node graph that can be built using one or all of the nodes of the model with any arbitrary depth.

With this rules, I realize that the only functionally complete crud generator that I have seen was Apple WebObjects Direct2Web… All others (JBoss SeamGen for example) are unable to deal with all the kinds of relationships in the Irreducible Complexity Model and, even without that limitation, are just unable to deal with requirements 2,3, and 4. because all of them force you to either violate transactionality by forcing you to save before navigation to the next node, or force you to pass all validation rules at a particular node before going to the next, or, have a really simple and powerless query by example UI.

Irreducible (Minimal?) Complexity: EntityModel (RelationalModel? DatabaseModel?)

I am not sure that the name Irreducible Complexity Entity Model actually fits what I am about to describe, but I was the best I can think of:

Lets think of an Entity Model (Database Model?, Relational Model?) that has at least one instance of each kind of entity relationship, so that it becomes representative of pretty much anything that can happen at any database:

• A One To One relationship
• A One To Many relationship

So we would have:

• TableA One To One TableB
  TableB One To Many TableC

But then, we remember that there are recursive relationships so the list now is:

• A One To One relationship to the same table
• A One To One relationship to another table
• A One To Many relationship to the same table
• A One To Many relationship to another table

So now we have:

• TableA One To One TableA
• TableA One To One TableB
• TableB One To Many TableB
• TableB One To Many TableC

But then we realize that there is si not representative of any case, because there is another kind of relationship, one that is “complex” (formed by 2 of the “simple” ones described before: Many To Many) so:

• A One To One relationship to the same table
• A One To One relationship to another table
• A One To Many relationship to the same table
• A One To Many relationship to another table
• A Many To Many relationship to the same table
• A Many To Many relationship to another table

So we have:

• TableA One To One TableA
• TableA One To One TableB
• TableB One To Many TableB
• TableB One To Many TableC
• TableC Many To Many to TableC (using TableCC as intermediate)
• TableC Many To Many to TableD (using TableCD as intermediate)

Now, with this one would think we have a representative case for each “conceptual” kind of entity relationship. Am I right? (For example Object Relational Mappers? offer a way to map relationships for their Object Oriented counterparts, and the only kinds of relationships that are supported by them (when going from the database to the object model) are: One To One, One To Many? and Many To Many?. (If going from the Object Model to the database, then "Inheritance" enters the game, so I guess the Irreducible Complexity Entity Model would have to include "Inherits From?" as a relationship type (note that Inherits From? is the only kind of relationship that can not be used in "reflective" way):

* A One To One relationship to the same class
* A One To One relationship to another class
* A One To Many? relationship to the same class
* A One To Many? relationship to another class
* A Many To Many? relationship to the same class
* A Many To Many? relationship to another class
* A Inherits From? relationship to another class

And so we get:

* Class A One To One Class A
* Class A One To One Class B
* Class B One To Many Class B
* Class B One To Many Class C
* Class C Many To Many to Class C
* Class C Many To Many to Class D
* Class D Inherits From Class E

But, then we realize there is another case, what if the relation is not to a concrete but to an abstract class?

• Composition
• A One To One relationship to the same class
• A One To One relationship to another class
• A One To Many relationship to the same class
• A One To Many relationship to another class
• A Many To Many relationship to the same class
• A Many To Many relationship to another class
• Inheritance
• A Inherits From relationship to another Concrete Class?
• A Inherits From relationship to an Abstract Class

And then (finally?) we realize that this "Concrete/Abstract" separation also applies to the Composition relationships:

• Composition
• A One To One relationship to the same abstract class
• A One To One relationship to the same concrete class
• A One To One relationship to another abstract class
• A One To One relationship to another concrete class
• A One To Many relationship to the same abstract class
• A One To Many relationship to the same concrete class
• A One To Many relationship to another abstract class
• A One To Many relationship to another concrete class
• A Many To Many relationship to the same abstract class
• A Many To Many relationship to the same concrete class
• A Many To Many relationship to another abstract class
• A Many To Many relationship to another concrete class
• Inheritance
• A Inherits From relationship to another Concrete Class?
• A Inherits From relationship to an Abstract Class

I wonder if I am missing a particular combination/ relationship kind… (or if there is a simpler way to express this…)