Vincent Massol wrote: > 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.
I was just thinking about that. The current document and the current space should not be part of the DAB, but of the context. So I change my vote to -1 for adding it to the DAB, +1 for adding it to the ExecutionContext. The Request is another good candidate, but not all requests will point to a document, and it will require more code, since the request has several implementations. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
