28 Jun
2009
28 Jun
'09
3:01 p.m.
On Jun 28, 2009, at 2:51 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
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
On Jun 28, 2009, at 1:53 PM, Thomas Mortagne
wrote:
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. 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. 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.