Re: Static Skins in prototype

> 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...

The reason I came with my approach though, was to avoid having a whole
raft of XYZMgr *prototypes* (not just object) defined throughout an
application. To me it seemed quite messy to have all these extra
"helper" Prototypes when conceptually collections of objects should know
how to manage themselves. The problem I ran into though is that there is
no way to define actions on collection properties but what I eventually
learnt was that mountpoints are a way of creating a "virtual" object
property in a prototype and using this gave me the work around to have
actions like "create" and "list" which need to work on collections of
objects. but really I still think this is rather a hack solution and the
best way forward would be to change helma to allow actions on collection
properties, though I realise this would only work for prototypes mapped
to relational db's since with xml db's you can have hetrogenious
collection properties (ie storing objects of diff Prototypes). My first
go at writing a patch to do this didn't go well, I will try again once I
have a bit of time.
 
> 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

exactly. Ideally instead of mountpoints, it makes sense for them all to
be collections, but you can then easily run into Helmas other big
limitation at the moment - "single homed" objects, i.e objects can only
belong to one collection (have 1 parent) for the purposes of callign
href() at least.
This is much harder to work around since an object you get from a
collection say:
/shelves/non-fiction/books/The+Complete+Helma

is the same as:
/authors/Helma+org/books/The+Complete+Helma

so which collection is this objects parent for the purposes of href() ?

Not sure if these issues can be addressed in the existing db mapping
system or whether they need to wait til the big changes in helma 2.0...

Maks