Re: User preferences

Hi

> I don't know. I have some systems that have it nicely solved.
> But I'm not sure if copying that would be the right way for BC.

Could you roughly sketch them?

Okay, I agree that we should not use Conf for that but rather a 
Preferences class that then does caching on a user-is-logged in basis if 
at all.

> No. That is not discussed here. 
> The discussion was floating about loading several, say defaults, without 
> specifying a method to keep them apart.
> As far as the API of Conf: is concerned you can't tell if a retrieved 
 > conf_value is factory_default or else. There is NO difference.

Yes, that is true. And I think that is a good thing: It is and should be 
transparent. We could - however - add an optional parameter to "get" and 
"set" that explicitely specify the configuration level to get/set from/to.

I could not see from your previous posts that you are against that. 
Explain me why, please.

>>  * Have a table entry for factory defaults with path XXX
>>  * Have a table entry for project (workspace) defaults with path XXX 
>>overriding the factory defaults.
>>  * Have a table entry for user defaults that are associated with each 
>>user with path XXX overriding factory and project defaults.
> 
> 
> To my opinion this is not clear. I do see here three paths specified that 
> are not unique (XXX). Yes, I know, it's an example.

The paths are unique within a configuration "level", i.e. factory 
defautl, worspace configuration etc.

> The real problem will show as soon as you want to load these table-
> entries. You're talking about 'preLoading' and configuring a 'loading-
> sequence' and 'load-conditionals', but this is already shot down from the 
> draft. I think it has to be specified again ?

Look at my changes to the draft [1] and point out what things are 
missing. I tried to include the ideas we agreed on the list.

I do not quite see the problem that should arise when configuration is 
loaded. When a path occurs that already has occured in a "lower" 
(workspace is above factory defaults), the "higher" (e.g. workspacer) 
overwrite the lower one.

You cannot tell where your configuration comes from, but that is not 
necessary when doing application development.

I agree that i makes sense to be able to get values from different 
"configuration levels" explicitely by additional parameters for an 
administration interface (to display the default values, for example).

I also agree that it make sense to have a "cache log" that exactly 
points out which value overwrote which other value so things are 
transparent.

However, I strongly believe that when developing you do not care about 
which level your configuration comes from: You always want the one with 
the highest priority.

>>I meant the meaning of "preferences" in the same way as "configuration". 
>>They are basically the same thing and not taking them as one thing makes 
>>everything more complex. With all configuration stored and handled by 
>>Conf, you only have one class to access them and overriding can be done 
>>by the configuration class.
>>
>>If you seperate system configuration and user preferences, you'd have to 
>>do the mergin and overriding in your user code: Everywhere you need it.
> 
> 
> I don't know. On first sight I would suggest that it is a typical task for 
> User: or Session: to use $myConf->set(path,value).
> Another option would be an extended class 'userPref' which does basicly 
> the same as Conf:. It totally depends on the nature of user-preferences.
> We should discuss that, but not in relation to Conf. (imo)

Okay, let's drop user preferences for now. Let's focus on Conf. Please 
read my changed proposal [1] and tell me what you like and what you dislike.


Manuel

[1] http://www.binarycloud.com/index.php/Drafts/NewConfigurationDraft
_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev