On Jun 28, 2009, at 1:53 PM, Thomas Mortagne wrote: > On Sun, Jun 28, 2009 at 10:40, Sergiu Dumitriu<[email protected]> > wrote: >> Vincent Massol wrote: >>> On Jun 27, 2009, at 2:46 PM, Thomas Mortagne wrote: >>> >>>> On Sat, Jun 27, 2009 at 10:48, Vincent Massol<[email protected]> >>>> wrote: >>>>> Hi, >>>>> >>>>> In order to implement SpacePreferencesConfigurationSource I need >>>>> access to the current space. >>>>> Hence I'm proposing to add String >>>>> DocumentAccessBridge.getCurrentSpace() >>>>> >>>>> Here's my +1 >>>> I think SpacePreferencesConfigurationSource should be in xwiki-core >>>> for now (until we have the new model) or it will just be a class >>>> full >>>> of calls to DocumentAccessBridge... >>>> >>>> Same for WikiPreferencesConfigurationSource. >>> >>> I see only 1 getProperty() call for each (and possibly - not even >>> sure >>> - one call to get the current space). >>> >>> What am I missing? > > The only job of SpacePreferencesConfigurationSource is to retrieve > data in the space preferences object. I don't see anything which is > not about accessing to the model, which is why i'm saying there is > almost only call to DocumentAccessBridge in this class. > > It's useless IMO to use the bridge in a component which is doing > nothing except retrieve datas in the model. The goal of the bridge for > me is to give some access for component which need simple informations > in the model and not to do a complete temporary model... > >> >> And the calls to the access bridge are OK, since they are supposed >> to be >> replaced with calls to the new model once it is in place, so all the >> code that needs access to the model *should* use the bridge. Once we >> have the new model in place, the default bridge implementation will >> use >> it instead of the old core. > > When the bridge already have all needed but we are mapping more and > more model in the bridge which is wrong IMO. > > I don't vote against it so if everyone is +1 go for it but i don't > like adding temporary code when there is no good reason.
Well there is a good reason and an important one: My take is that it's better to partition modules by domain rather than partition around a technological barrier. This mean that I think it's better to have all configuration related code as sub modules of xwiki-configuration rather that in xwiki-core for example. Now we could have xwiki-configuration-default and xwiki-configuration- document and have xwiki-configuration-document depend on xwiki-core but somehow it doesn't like right since this is not what we'll want in the future. Hence the idea of putting everything for now in xwiki-configuration- default and using the bridge. Re the bridge I think we should start creating the xwiki-module and have a model separated from the storage for starters + put the current wiki/space/doc in the Execution Context. We could also refactor the XWiki Context to get the current space/doc from the Execution Context so that we don't duplicate the information. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
