My Mocha stuff consists of an "abstraction layer" and an "object engine" that currently run on top of Web Crossing which is a proprietary product. What I'm trying to do with Mocha would be what I consider "commodity software" - software that should be free and therefore it needs something to run on that is free.

Both the Mocha Object Engine and the Mochascript Library are written in Javascript and "feel good" together with Helma. Generally, I feel that Helma fits the way I'm thinking. Having said that, I'm not a fan (yet) of the skin/macro concept and I'm still digesting Hannes' relative willingness to accept relational databases as "not from hell"

• but I'm starting to get the picture (ie. pBeans + Groovy Beans).
  
  Here's why I think the skin/macro stuff doesn't fit right with the Mocha concept: I believe it draws the line between application logic and layout to early. I think you Helmaists have started to discover this yourselves: When you start generating HTML dynamically (a similarity between the Mochascript lib and the AntvilleLib) and when you start to add some kind of GUI-translation lookups then you remove both HTML markup and GUI-Text from the skins - and you're left with gibberish of mixed layout, string and content lookups. I claim that kind of gibberish is more difficult for a non-programmer to disekt than a Javascript syntax with a very high level of abstraction.
  
  Mocha adds an additional level of abstraction where all of these lookups are expressed in Javascript. I call these elements "Mocha Objects" and they might look for example like this:

 
+ openPage({backpath:'hide'}); 
+ openSidebar() + makeList('siblings') + closeSideBar(); 
+ openContentBlock(); 
+ makeTitle({style:'alert'}) + makeDescription(); 
if (userIs('editor')) { 
	+ openForm(); 
	+ makeTextarea('content'); 
	+ makeDropbox('status',['Pending','Active',Resolved']); 
	+ makeButton('Save Changes','submit'); 
	+ closeForm(); 
} 
else { 
	+'You need to ask your editor to make the changes.'.lookup(); 
} 
+ closeContentBlock(); 
+ closePage(); 

Translations and string customizations are handled by a lookup string method that checks for available string replacements based on a hash lookup. If I wouldn't be against software patents, I would patent this.

When running Mocha on top of Helma, a .hac file would basically call the Mocha Object Engine that determines which Mocha Objects need to be evaluated in order to respond to the current request. That collection of Mocha Objects is then evaluated and the result returned to the client. Skins wouldn't really be needed in this picture. However, the skins in Helma provide a security and access control layer that allows a user to make edits that are jailed from the applications Javascript environment. Adding a separate second tier Javascript environment in which Mocha Objects are evaluated would be the trick.

But I might be changing my mind about that skin/macro criticism: In earlier days, I once implemented a Mochascript library that ran on the client-side (with Broadvision on the server-side). I never intentionally abandoned that concept - I just didn't have the time to maintain/update it. Think of skins as an additional layer of Javascript code that will dynamically generate the HTML markup on the client-side. Client's have plenty of CPU power available to first evaluate Javascript before rendering the resulting markup. The Mochascript library on the server side would then generate/output client-side Javascript code instead of HTML, like both my Mochascript lib and for example the AntvilleLib do now. Helma's skins are the intersection between HTML and server-side macro calls. Mocha's "skins" would be the intersection between server-side and client-side Javascript - on the server-side, we would basically never see an HTML tag.

Some might argue that Javascript is not as easy to learn for a non-programmer as for example python. I believe while that might be true, the reality sports a bigger picture: Sooner or later "everybody" has to learn that kind of syntax anyway. The advantage of a "mono-syntax" environment from the client-side to the server-side and beyond (Java, C, etc.) by far outweighs the learning curve. Speed can be gained by abstraction instead of syntax.

So, Mocha is mainly about abstraction and how different levels of abstraction are layered. Helma might be the ideal underpinnings for Mocha.

27.05.2004, 09:41