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
