Today I'm putting together the first version of the Hop app that runs this site. It'll be primarily interesting to Hop developers though, since it's just a very raw proof of concept. Actually, it's interesting not because it's a blogging tool - there are Hop-based weblog-type apps which are much more elaborate -, but because it uses a whole new skin-based application framework that cuts down the amount of code quite a bit.

The code is in the CVS now and you can browse through it. Still not ready to be packaged, sorry bout that. The code by itself may be confusing because there's some cross-prototype action going on, so here's a linked reading guide:

Every HopObject in this application has three basic modes in which it can be accessed via a browser. They are defined by three files in the hopobject prototype: main.hac, edit.hac, and create.hac and inherited by every other prototype.

main.hac lets people view an object (like you are doing right now with this page), edit.hac lets them edit it, and create.hac lets them create new child objects beneath it.

The first thing each of this action does is to set a global page skin in the response object to be rendered after the request is done. By doing so, we delegate repeating layout stuff and can concentrate on what's special for the object and action we're dealing with. That's why you won't find a lot of HTML markup in the henso code.

The next thing is that a function is called on the current HopObject to find out if the current user is allowed to perform this action. In the hopobject version of these functions, main.hac may be called by all users while edit.hac and create.hac are generally prohibited. Application prototypes can override this to control user access. For example, this is the code that makes a weblog item editable by its author, while anybody who is logged in may create a comment on it. Of course, real world application will have much more complex rules, but they will fit nicely into this scheme.

If the current action is allowed for the user on the current object, a function corresponding to the action is called on the object. Again, the functions defined in the hopobject prototype do nothing except for throwing out a "not implemented" (which will look like this, thanks to the global skin set earlier). Application prototypes can override either the function or the skin or both to make something out of the action. For example, when a new weblog item is created, function weblog.doCreate() will render weblogitem/create.skin. Note that in typical Hop fashion, we check if the user submitted some meaningful data. If so, we do what we have to and redirect to the main view. If not, we display the object editor.

Skins render and display content. Skins are pieces of layout that can be overridden on an application level to customize the application, although this isn't implemented in the current version of this app. For example, here is a skin that displays a comment, while this one renders an editor for it.

The <% ... %> tags inside the skins are called macros. Macro names consist of a handler name and the macro name, separated by a dot (".") and a list of attributes. Possible handler names are "this" to access a macro in the current object, a prototype name to access a macro in the next object with that prototype down the request path, "request" and "response" to access data in the request and response objects, an finally "param" to access properties of the optional second argument in the renderSkin-functions. If a macro doesn't have a handler name it is considered a global macro defined in the global prototype.

There are two kinds of macros, task-specific ones and generic ones. The task-specific ones reside in application prototypes and know exactly what they do, like the loopLogItems macro in the weblog prototype. The generic macros reside in the hopobject prototype and perform tasks that are possible on any kind of object, like getting a property by name, getting an editor for a property, rendering a link or a skin on the object, or looping through child objects.

That's it for today. Let me know if anything is unclear. Tomorrow there'll be more, including something to download and play with.

In other news, I also gave Greymatter a try today. It's a very nice system. The approach is very different from what I'm doing, however. To sum it up in one sentence, Greymatter is optimized to set up individual blogs in a generic hosting environment, while Hop based systems are more difficult to install, but are geared towards high performance multi-site stuff (think Manila or Blogger).

Today's Hop snapshot introduces two new functions: res.writeBinary() and countActiveUsers().

So I'll dive skin-deep then. Great!

yeah ;) let's dive.

Greymatter is nice, except ist p(!)erl

right, slauti, for me the perfect solution would be the same in php

Not logged in. Click here to log in.