Re: managing helma collections

hi tobi,

[email protected] schrieb:
> i came across this because i am currently trying to find a generic approach towards listing hopobject collections in a flexible way.
>
> ie. i'd like to have all items of a collection in a table-like layout, with two-level grouping (e.g. alphabetical and page number) and sortable header fields.
>
> imho it's nothing exotic, just what we are used from desktop applications like a mail client where such an item is represented by a message and the collection by all e-mails. actually, it's like a mirror of what's going on in the database table itself. 
>
> i consider it a very basic and important way of representing data records which is almost ubiquitous when building applications with helma.
>
> currently, i don't see a really feasible option to realize such a thing with helma, at least when avoiding subnodeRelation settings or directDB queries. (although both could be a solution, nevertheless.)
>
> what do the other worshiped helma users and application developers think: 
>
>  * is there a way to make this happen without defining much too many collections in type.properties?
>  * is subnodeRelation / directDB the way to go?
>  * could it be done easier and the helma-way simply by adding some nifty helma features?
>   
I posted some code to this list a while ago, which somehow solved the
problem for us: http://helma.org/pipermail/helma-user/2007-May/007032.html
It basically transforms a SQL-query into a HopObject-collection. I tried
to mimick the behaviour of Helma's collection, but failed to acchieve
the smart caching mechanism, that Helma provides. Caching would then (if
needed at all) be implemented at a different level. E.g. by caching the
result of the query for a certain amount of time, or if that is not
acceptable then at least by turning on the query-cache at the
database-server.

Nevertheless I also long for a mechanism in Helma, which does not force
me to define multiple collections only to use a different accessname, or
a different sort order (and one, that performs well for large collections).

   michi