Reactive/Declarative absolutely needs to be complemented by a procedural language such as JavaScript, and integrated so both work together. This is straightforward - just provide for "events" on tables, using a well known language (e.g., JavaScript).
Totally agree that 1-size-fits all is a mess. I think a database-focused "Domain Specific Language" can be tuned for performance, since it can (should) know about the database, costs of SQLs, and so forth. As long as it is extensible with an Imperative Language.
I see your concern, but I think it is solvable... First, the original article was about transaction (save) processing, so populating form fields is important but different.
You are absolutely right that changes can cascade A LOT, but that can be addressed by pruning the Reactive Expressions - on a per-transaction basis - to just those that apply to the actual changes. So a change to an order date affects no dependents, and it's a simple 1-row update. And, changes can be done efficiently, such as 1 row update for totals (vs. an aggregate query).
This enables Reactive to scale to very large applications, since it should be possible to limit the SQLs to no more than would be coded by Imperative code.
It is a product. A service actually, so you can fiddle without download or install, at espressologic.com. Earlier generations were Wang Pace and Versata. We'd love to hear your reaction.
On the client side, EL is a very close approximation, and Microsoft has done some work: http://msdn.microsoft.com/en-us/data/gg577611.aspx
Slashdot Mirror
Reactive/Declarative absolutely needs to be complemented by a procedural language such as JavaScript, and integrated so both work together. This is straightforward - just provide for "events" on tables, using a well known language (e.g., JavaScript).
Yes, the concept is not new, but Web 2.0 is a good angle. The author (Espresso) has made a REST server out of it.
Wang/Pace and Versata used this approach. Several thousand production apps between the 2.
Totally agree that 1-size-fits all is a mess. I think a database-focused "Domain Specific Language" can be tuned for performance, since it can (should) know about the database, costs of SQLs, and so forth. As long as it is extensible with an Imperative Language.
I see your concern, but I think it is solvable... First, the original article was about transaction (save) processing, so populating form fields is important but different. You are absolutely right that changes can cascade A LOT, but that can be addressed by pruning the Reactive Expressions - on a per-transaction basis - to just those that apply to the actual changes. So a change to an order date affects no dependents, and it's a simple 1-row update. And, changes can be done efficiently, such as 1 row update for totals (vs. an aggregate query). This enables Reactive to scale to very large applications, since it should be possible to limit the SQLs to no more than would be coded by Imperative code.
It is a product. A service actually, so you can fiddle without download or install, at espressologic.com. Earlier generations were Wang Pace and Versata. We'd love to hear your reaction. On the client side, EL is a very close approximation, and Microsoft has done some work: http://msdn.microsoft.com/en-us/data/gg577611.aspx