28 Jun
2009
28 Jun
'09
2:55 p.m.
Thomas Mortagne wrote:
On Sun, Jun 28, 2009 at 10:40, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
What defines a code is not the individual method calls in it, but the
logic it creates. Pseudocode is much more significant than API usage.
And the bridges and the real model are just two placeholders for this
API usage, mostly irrelevant to the inner logic. When the model will be
ready, the logic of the configuration component will be the same: ask
the preferences for the current space what the admin wants. How we ask
this is just a detail.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
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.