Forgot to mention that indeed, we have some limitations in XWiki now in handling default values for an object's properties both in the UI and in the platform. AFAIK, using the UI at least once has the tendency of initializing (when submitting) object properties with empty (or first, if it`s a select) values.
Thanks, Eduard On Mon, Apr 25, 2016 at 1:04 PM, Eduard Moraru <[email protected]> wrote: > 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 < > [email protected]> wrote: > >> On Thu, Mar 31, 2016 at 2:54 PM, Vincent Massol <[email protected]> >> wrote: >> >> > >> > > On 31 Mar 2016, at 13:02, Alexandru Cotiuga < >> [email protected]> >> > 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 >> >> >> > > >> > > An issue has been created at http://jira.xwiki.org/browse/XWIKI-13274 >> > and a >> > > first pull request at >> https://github.com/xwiki/xwiki-platform/pull/472, >> > 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 >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> > >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
