On Jun 28, 2009, at 2:51 PM, Sergiu Dumitriu wrote: > 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 it has always been agreed to put it in the EC. That's not the problem. The pb is that it's not easy to do so right now. That's why we've put currentDoc() in DAB for now. -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
