[Helma-user] Static Skins in prototype

[tobias.schaefer at orf.at]

hi maksim

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

this is an interesting point you make, something that's bugging me for long as well, and right now diving back into the Antville code.

here are my ideas of how to make mountpoints more flexible with current helma installations at least to provide generic functionality -- which is what those FooBarMgr prototypes need most of the time:

 1. define the collections used in the mountpoint in the mountpoint's parent (thanks to robert for the hint)
 2. define callbacks in the parent prototype for certain tasks / definitions needed in the mountpoint
 3. use subskins either in a global skin or in a skin of the parent's prototype
 4. rely on naming conventions

this way, an abstract Manager prototype could be created fulfilling the individual tasks for each collection and thus replacing a dozen FooBarMgr prototypes -- at least theoretically.
:)

nevertheless, if helma could provide better means to solve this issue more elegantly, i would be happier.

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

actually, you should be able to add one object to as many different parents using the generic object/collection references recently introduced to helma.

http://helma.org/bugs/show_bug.cgi?id=516

as for what concerns the href() output you always can find ways to re-model it overwriting the method itself for the desired prototype -- although most of the time i find it worthwhile to have only *one* URL for each object.

MyProto.prototype.href = function(action) {
   if (action === "foo") {
      return "http://localhost:8080/foo";
   }
   // call the "original" href() method
   return HopObject.prototype.href.call(this, action);
};

furthermore, it might be worth looking at the getChildElement() method at this point, too.

http://helma.zumbrunn.net/reference/core/HopObject.html#getChildElement

ciao,
tobi