[dev] [commits] Horde branch master updated. f61fdaee6bb5fee15abe792219b02a0947925028

[Chuck Hagenbuch]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> The branch "master" has been updated.
>> The following is a summary of the commits.
>>
>> from: 5643dee22aa524776bd6caf14625c3acc3858002
>>
>> f61fdae Right now _getRelatedTags() is the difference between my  
>> task list loading in .5 seconds and it taking 4-5 seconds to load,  
>> even after the Horde_History cache improvements. It also is getting  
>> tags that aren't from the current view because Future tasks aren't  
>> accounted for.
>>
>> -----------------------------------------------------------------------
>>
>> commit f61fdaee6bb5fee15abe792219b02a0947925028
>> Author: Chuck Hagenbuch <chuck at horde.org>
>> Date:   Wed Jul 3 00:33:57 2013 -0400
>>
>>   Right now _getRelatedTags() is the difference between my task  
>> list loading in .5
>>   seconds and it taking 4-5 seconds to load, even after the  
>> Horde_History cache
>>   improvements. It also is getting tags that aren't from the  
>> current view because
>>   Future tasks aren't accounted for.
>>
>>   I think if we want to keep the related tasks top bar, we need to  
>> put that list
>>   together as we go through the list of tasks, where we're already  
>> fetching the
>>   tags for each task and displaying them next to each one. That'll  
>> avoid a *lot*
>>   of unnecessary queries.
>
> This may be true, but can you wait until there is some fix in place  
> before removing it in the stable git branch? This way, we won't  
> accidentally remove this functionality from the next bug fix release.
>
> FWIW, this is also the same mechanism that we use in all the apps  
> that use tags-as-navigation such as Trean and Ansel. I think we need  
> to improve either Content_Tagger or Core_TagBrowser instead of  
> moving the browsing functionality out of it and into the  
> application-land code.

Yeah, I saw that it was the same mechanism, and agree it needs to be  
improved. Is this really that useful a feature right now though that  
we need to keep it in exchange for pages loading 8x slower? It just  
seems to filter the existing view, and I'm not sure that filtering  
tasks by multiple tag criteria is that useful. Obviously there might  
be another use case out there that heavily uses tagging to organize a  
ton of tasks, but anyone doing that right now is going to spend a LOT  
of time waiting.

Another option that doesn't preserve multi-tag filtering would be to  
show the tags in the sidebar like we do for Trean - that'd be a much  
lighter query at least.

-chuck