Re: [xwiki-commits] [Issue] Commented: (XWIKI-942) Customize default cache duration
On Mar 13, 2007, at 10:02 AM, Pablo Oliveira wrote:
On Mar 13, Sergiu Dumitriu (JIRA) wrote :
P.S.: It's so bad that there's no better way of getting configuration parameters. There should be a separate component, accessible from anywhere.
I really do agree here. This would be a great step towards a more modular XWiki. Even if not related: It's really annoying to have to pass an XWiki instance to the storage module, just so it can retrieve some conf parameters...
We'll have to take a decision here in the future: 1) either we provide a configuration per component 2) or we provide a global configuration I prefer 1) because: - a component is encapsulated completely in a JAR - a component shouldn't see by default configuration from other components. It's these other components who should offer APIs to return configuration data if required -Vincent
On Mar 13, Vincent Massol wrote :
We'll have to take a decision here in the future: 1) either we provide a configuration per component 2) or we provide a global configuration
I prefer 1) because: - a component is encapsulated completely in a JAR - a component shouldn't see by default configuration from other components. It's these other components who should offer APIs to return configuration data if required
I also like 1 better. Yet I think from a user point of view, it seems more natural to edit a single xwiki.cfg file than to edit a conf file inside some component's JAR meta data. So I would still allow some global way of overriding components configuration from a single configuration source. Pablo
On 3/13/07, Pablo Oliveira <pablo.oliveira@enst.fr> wrote:
On Mar 13, Vincent Massol wrote :
We'll have to take a decision here in the future: 1) either we provide a configuration per component 2) or we provide a global configuration
I prefer 1) because: - a component is encapsulated completely in a JAR - a component shouldn't see by default configuration from other components. It's these other components who should offer APIs to return configuration data if required
I also like 1 better.
Yet I think from a user point of view, it seems more natural to edit a single xwiki.cfg file than to edit a conf file inside some component's JAR meta data. So I would still allow some global way of overriding components configuration from a single configuration source.
Pablo
I also think that we need both. -- http://purl.org/net/sergiu
We can use both . if can it is better for us Regards -Phung Nam On 3/13/07, Sergiu Dumitriu <sergiu.dumitriu@gmail.com> wrote:
On 3/13/07, Pablo Oliveira <pablo.oliveira@enst.fr> wrote:
On Mar 13, Vincent Massol wrote :
We'll have to take a decision here in the future: 1) either we provide a configuration per component 2) or we provide a global configuration
I prefer 1) because: - a component is encapsulated completely in a JAR - a component shouldn't see by default configuration from other components. It's these other components who should offer APIs to return configuration data if required
I also like 1 better.
Yet I think from a user point of view, it seems more natural to edit a single xwiki.cfg file than to edit a conf file inside some component's JAR meta data. So I would still allow some global way of overriding components configuration from a single configuration source.
Pablo
I also think that we need both.
-- You receive this message as a subscriber of the xwiki-dev@objectweb.orgmailing list. To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org For general help: mailto:sympa@objectweb.org?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
On Mar 13, 2007, at 10:29 AM, Pablo Oliveira wrote:
On Mar 13, Vincent Massol wrote :
We'll have to take a decision here in the future: 1) either we provide a configuration per component 2) or we provide a global configuration
I prefer 1) because: - a component is encapsulated completely in a JAR - a component shouldn't see by default configuration from other components. It's these other components who should offer APIs to return configuration data if required
I also like 1 better.
Yet I think from a user point of view, it seems more natural to edit a single xwiki.cfg file than to edit a conf file inside some component's JAR meta data. So I would still allow some global way of overriding components configuration from a single configuration source.
Yes you're right... There are 2 different types of configurations: - static ones - dynamic ones that can be modified by the user So component should have a default configuration so that they should work out of the box but users should be allowed to modify the configuration through an interface (in the wiki itself for example as it's currently done maybe). I'm not entirely sure about all this yet. Need to think more about it. Thanks -Vincent
On 3/13/07, Vincent Massol <vincent@massol.net> wrote:
On Mar 13, 2007, at 10:29 AM, Pablo Oliveira wrote:
On Mar 13, Vincent Massol wrote :
We'll have to take a decision here in the future: 1) either we provide a configuration per component 2) or we provide a global configuration
I prefer 1) because: - a component is encapsulated completely in a JAR - a component shouldn't see by default configuration from other components. It's these other components who should offer APIs to return configuration data if required
I also like 1 better.
Yet I think from a user point of view, it seems more natural to edit a single xwiki.cfg file than to edit a conf file inside some component's JAR meta data. So I would still allow some global way of overriding components configuration from a single configuration source.
Yes you're right...
There are 2 different types of configurations: - static ones - dynamic ones that can be modified by the user
So component should have a default configuration so that they should work out of the box but users should be allowed to modify the configuration through an interface (in the wiki itself for example as it's currently done maybe).
I'm not entirely sure about all this yet. Need to think more about it.
Thanks -Vincent
Maybe http://jira.xwiki.org/jira/browse/XWIKI-648 helps? -- http://purl.org/net/sergiu
participants (4)
-
Pablo Oliveira -
Phung Nam -
Sergiu Dumitriu -
Vincent Massol