Helma Logo
main list history
previous version  overview  next version

Version 6 by tobi on 22. June 2006, 18:16

A newbie's way creating a Helma application is long. Too long IMHO.

First of all you need the software:

1. The Helma package
2. Sun's Java virtual machine
2. A working (My)SQL database installation

That should be easy -- as long as this is not the first time you need to install a database software.

Early frustrations will manifest when trying to code along the tutorial at helma.org; besides being a part of the Helma documentation (which is the most important resource for a beginner but alas, also the most neglected by its maintainers) it lacks a positive output because it is jittering between introducing Helma concepts and creating the necessary database tables.

Thus, our poor newbie is disturbed in his efforts to understand Helma by having to switch periodically to a completely different task -- setting up the SQL database.

In the worst case such distraction turns a frustrated user completely away from Helma. Thus and in any case, it is necessary to hide or remove the tasks which are not related to Helma (which is writing JavaScript code and not MySQL statements).

<strong>Conclusion:</strong> Helma needs a better tutorial which teaches the basic concepts without requiring knowledge about SQL databases or steady interference with Helma-unrelated tasks. This could be achieved either with making more and better use of Helma's tools or simply by using the (or even a revised) internal database only.

But let's assume the pychological strain is not that high, yet, and the user continues with her enterprise. She will have to pass the next hurdle by getting along with the concept of database-mapping certain fields of a HopObject in an extra file called type.properties located in the HopObject's prototype directory.

Besides understanding the concept of object-to-relational mappings one must get the syntax of Java properties, another syntax, a <em>third</em> syntax counting in SQL so far.

Not to mention what it might take for a novice Helma developer to cope with database URLs like jdbc:mysql://localhost/antville or driver settings like org.gjt.mm.mysql.Driver. (Not that there is something wrong with these; it's just that at a certain level of helmatic innocence you simply should not have to see such bloody intestines.)

<strong>Conclusion:</strong> Helma needs a much simpler and much more JavaScript-compliant way to define server, application, database and type properties. Especially the latter need to be as close as possible to the HopObject they refine.

Having absorbed this visceral shock, and still wanting to learn to know Helma, our user might finally get to the point of finalizing the tutorial. In fact, he will start to play with the created code, modify and extend it. Pretty soon he will wonder "Well, isn't there a way to get the length of a MimeObject's content?" -- or: "What was the syntax of a File object's mkdir method again?" -- and where do you turn to with such questions than to the reference at helma.org?

But oh! -- babap! cancel your ticket! -- Unfortunately, this very documentation is still missing and it's for years now (or so And where do say some people). Well, you might counter, I am sure I have seen this documented somewhere. And I bet you are absolutely right because it <em>surely is</em> documented somewhere. It's just a mess turn to find with such questions better than to the exact place between dev.reference at helma.org, the mailing-lists and henso.com.org?

But no -- babap! cancel your ticket! --, unfortunately, this very documentation is still missing and it's for years now (or so do say some people). Well, you might counter, I am sure I have seen this documented somewhere. And I bet you are absolutely right because it <em>surely is</em> documented somewhere. It's just a mess to find the exact place between dev.helma.org, the mailing-lists and henso.com.

<strong>Conclusion:</strong> Helma's documentation is much better than it was in 1998. However, it's still not good enough. It needs careful maintenance and reliable completion. Moreover, documentation has to be centralized. People learning about Helma do not tend to elaborately read through mailing-list archives or a developer's blog (most of the time they don't even know about the latter).

But it gets even worse: imagine the user has the very simple and basic idea to output an HopObject's href in a skin -- hardly to accomplish (except writing the macro for yourself). Or ever pondered about including a skin within a skin? It's not the missing documentation, these are missing features! And such basic ones that I regularly cannot believe they are really not included in Helma.

<strong>Conclusion:</strong> Helma needs (easy means, e.g. libraries, to provide) "fattened" HopOjects, to reduce the amount of everyday code, e.g. with the help of href and skin HopObject macros.

The same, btw., applies to application setup and management as well as database mapping (which is already covered in a section above).

<strong>Conclusion:</strong> Helma needs setup and introspection support for application and property files (I know, there's a lot of stuff happening here, lately, but it needs to be much more present and intuitive). Of course,  with the right hints for the best third-party IDE available and its configuration.

Well, maybe the layperson in this story simply takes some code snippets from another application because it really does wicked stuff (like adding round corners and a breezy gradient to an uploaded image). Unfortunately, this snippet needs some adaptation, it does not work "out of the box" -- but the user has no idea where to look at inside this strange code from outer space...

<strong>Conclusion:</strong>: Helma needs a simple approach to its developer tools (which are coming up, finally). Couldn't there be some kind of layer that one could switch on in any Helma application and which gives full access to inspector, shell, debugger and the like? It should be simply there. At least for the absolute beginners.

Finally, another gorgeous application will see the light of the day, I am sure! And there begins another story, which must be written another day: The story of coding conventions, bug reporting and becoming a committer. Or something like that.