Hi,
Sorry for the late reply, but why not just use the ConfigurationSource API?
We already have something similar implemented in SpacesConfigurationSource
and more generically in DefaultConfigurationSource through
CompositeConfigurationSource which allows specifying an ordered list of
other locations to try.
Maybe we need to make SpacesConfigurationSource a bit more generic by
having it be configured which SpaceConfigurationSource to use. Right now I
think it`s a bit too coupled to the XWikiPreferences-based
SpacePreferencesConfigurationSource implementation, but the general idea
should be good.
Thanks,
Eduard
On Thu, Mar 31, 2016 at 4:39 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On Thu, Mar 31, 2016 at 2:54 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
> On 31 Mar 2016, at 13:02, Alexandru Cotiuga <
alexandru.cotiuga(a)xwiki.com>
wrote:
Hi devs,
As I was working on the Forum Application, which depends on Ratings
Application, I noticed that the rating configuration doesn't work as
expected on the Nested Spaces versions of XWiki.
For example, having A.WebPreferences with a XWiki.RatingsConfigClass
object, the configuration does not apply to A.B.WebHome, because the
configuration is set at space level, without inheritance to the below
levels.
> As a solution for this I propose to create a
new Api
> (getConfigurationDocument()) in the Ratings module which will check,
> starting the current document, and get the first ancestor that holds
the
XWiki.RatingsConfigClass object and use that as configuration document,
keeping the fallback to the XWiki.RatingsConfig document.
What I don't like about this solution is the fact that once you add a
XWiki.RatingsConfigClass
object to A.B you completely overwrite the configuration from A, while you
may simply want to overwrite just one configuration property. Of course,
this raises the problem of knowing if a configuration property is set or
not. The empty string may have a meaning.
Also, note that this is a generic need. Other applications might want the
same configuration inheritance. As Vincent suggested, we could create a
generic configuration source for this.
Thanks,
Marius
,
but
without having been discussed here before.
WDYT?
Sounds good to me. I gave several comments in the PR. One important one
is
to introduce a RatingsConfiguration component to
hold the Ratings
module’s
configuration and have the various other Ratings
components use it,
including the ScriptService since right now there are at least 3 places
getting the config.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs