[Helma-user] managing helma collections

tobias.schaefer at orf.at tobias.schaefer at orf.at
Tue Aug 7 13:46:47 CEST 2007


hi michi

thanks for reminding me on your solution.

i am not sure but does this look like you have already started an approach similar to what joshua suggested with his 5 points plan in his mail?

of course, i like the idea of having such a wrapper (or proxy) object making such flexible orders possible with current helma installations! it's better than waiting for helma 2.

anyway, for an inclusion in jala the code needs to be more complete and compatible (see knallgrau.Base); i guess it will be the same for helma modules. so, would you want to elaborate on this?

fwiw, i consider caching these queries as inevitable.

ciao,
tobi


Michael Platzer wrote:
> hi tobi,
> 
> tobias.schaefer at orf.at 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
> 
> _______________________________________________
> Helma-user mailing list
> Helma-user at helma.org
> http://helma.org/mailman/listinfo/helma-user



More information about the Helma-user mailing list