28 Jun
2009
28 Jun
'09
2:31 p.m.
On Jun 28, 2009, at 1:53 PM, Thomas Mortagne wrote:
On Sun, Jun 28, 2009 at 10:40, Sergiu
Dumitriu<sergiu(a)xwiki.com>
wrote:
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
Vincent Massol wrote:
> On Jun 27, 2009, at 2:46 PM, Thomas Mortagne wrote:
>
>> On Sat, Jun 27, 2009 at 10:48, Vincent Massol<vincent(a)massol.net>
>> 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.