User preferences

> > Moving to a different configuration structure is another story.
> > I suspect you can't use Conf:, neither current, neither proposed, in order 
> > to implement a different configuration interface.

<snip>

> >>This would effectively change the possible levels and the add a "user" 
> >>field to the conf table:
> > 
> > 
> > Pretty dangerous concept. Though it is a enlightening idea.
> > I truly doubt that it's usefull in a server environment.
> > Please do not understand me wrongly: I just have doubts.
> 
> Okay, so how would you implement user configureable settings 
> consistently and so that developers do not need to hack things up?

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.

> >>  * levels: factoy defaults, workspace wide defaults, language specific 
> >>workspace wide defaults, user defaults
> > 
> > It depends totally on how BC manages to have these values seperated.
> > Current, they have a different path.
> 
> Sorry? As far as I imagined the things we discussed here, you first load 
> factory defaults, then load other configuration and overwrite the 
> configuration values with the same path.

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.
I think the points you brought in, are in need for an own discussion 
thread.

>   * 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 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 ?

> > I do not understand this without a clear implementation example on a 
> > server. I also do have problems with the concept naming:
> > Conf is one thing, Preferences another one, there are Parameters and 
> > Definitions as well (ndf). Maybe more. Some have defaults, some can/must 
> > nbe changed, other ones can be overriden. They all are implemented using a 
> > php_array.
> > But to refer to them *all* as Conf: is for me 'a bridge too far'.
> > At least at this moment.
> 
> 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)

wim niemans

_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev