[Helma-user] Static Skins in prototype

[Joshua Paine]

Maksim Lin for technical support mailling lists wrote:
> I've recently been working on just this kind of rails-like scaffolding
> code and I think I have come up with a reasonable way of doing this in
> helma - by using mountpoints extensively.
> 
> The design pattern I have come up with is of always defining a _children
> for every prototype which is a collection of all the prototypes objects.

Two problems.

First, the one that has been bugging me from the start:
JavaScript already makes it easy to call methods of objects in different 
contexts. I'm only just getting started with Helma, but I'm pretty sure 
you can build all the stock CRUD into HopObject but have it called by a 
SomeObjectMgr object or whatever is the natural parent of SomeObject. 
And it's better to do it that way because...

Doh! Second, this proposed convention allows only completely flattened 
database relations and/or object hierarchy, i.e., no hierarchy and no 
relations. To keep using the generic Books objects we've used elsewhere, 
what if Books are properly children not of Root but of Shelves? 
Shelf._children can't be collection(Shelf) because it has to be 
collection(Book)!

Of course this can be worked around with more mountpoints.

mysite.com/shelves/Non-Fiction/books/The+Complete+Helma

And really that's not too bad. But I'm building a sermon audio archive, 
and we want to be able to browse (among other methods) by Scripture 
passage, so I have to choose between:

mysites.com/NT/Acts+of+the+Apostles/Some+Sermon
and
mysites.com/NT/Acts+of+the+Apostles/sermons/Some+Sermon

Aw heck, I don't know. The second wouldn't be that bad I guess, except 
that there's nothing else going on inside Acts+of+the+Apostles. I'm not 
going to also have /commentaries or any such thing, so the extra 
/sermons url chunk is just noise. I might go for it anyway if it bought 
me some important capability I couldn't get otherwise, but I'm convinced 
it doesn't, since we already have 
SomeObject.prototype.someMethod.call(context,arguments).

Once I build more of this app I'll start trying to put together how it 
makes sense to me. As it turns out, in the case of this site scaffolding 
would have been nearly pointless: the only objects that a regular site 
admin would manipulate directly are Sermons. The complexity comes in the 
different ways they have to be wired into behind-the-scenes collections 
to enable access by date, by Bible book, by topic, etc..

-Joshua

P.S. - We need an equivalent word to 'pythonic', and it would be so much 
better if it were anything but 'javascripty'.