Unit setting colletions

[Alexander Obuhovich]

1. Right now we collect some unit config settings (e.g. RewriteListeners, AggregatedTags) into a collections, that are stored in kApplication class instance.

If we'll be implementing tag filter concept (https://groups.google.com/d/topic/in-portal-dev/epuAEK7n3NU/discussion), then we'll have one more collection as a result.

Currently collection adding and using isn't very straight forward process and we should work to make it easier to use.

2. Also we cache all collections however we must create instances of all objects that store collections on In-Portal start even if they won't be used (e.g. aggregated tag list).

To solve this we might need to separate cache into one, that is used at every page and other on-demand caches. However that might result in additional sql queries (1 extra sql query per cache restore) if Memcache isn't used.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Alexander Obuhovich]

I have another idea to solve problem described in 2. item:

Create 2 classes:

• kUnitSettingCollection - data collected for a single settings across all unit configs
  
• kUnitSettingCollections - all created collections
  

Class kUnitSettingCollection would have following methods:

• scan/process(kUnitConfig $unit_config)
• add($key, $value)
• getFromCache()
• setToCache($data)

Class kUnitSettingCollections would have following methods:

• getCollectionBySettingName($setting_name)
• addCollection(kUnitSettingCollection $collection)

At the end we'll have all collections in an easy manageable form - objects. Then we can:

1. store them (serialize) in cache more easily
2. use them in corresponding classes only when classes are instantiated
3. easy way to apply custom processing to collection elements (e.g. rewrite listener sorting) by extending kUnitSettingCollection class

[Dmitry A.]

Hi Alex,

My main questions are - does it impact (rank from 1 - 5):

1. Developer (development process from how it's done now): old / new

2. Performance: old / new

3. Flexibility: old / new

Thanks.

DA

[Alexander Obuhovich]

They all should stay the same, because unit config format doesn't change. What changes is only way how data, collected from unit configs is being processed.

Since we add new collections very rarely, then this improvement (that should easy adding of new collections), won't be much of improvement right away. But I see no point in adding new collection old way if we can improve the process for further collections.

[Dmitry A.]

Thanks for clarification.

Please create this task for 5.3.0 then

DA