27 Jun
2009
27 Jun
'09
10:48 a.m.
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
Thanks
-Vincent
27 Jun
27 Jun
2:46 p.m.
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.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
6:50 p.m.
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:
I see only 1 getProperty() call for each (and possibly - not even sure
- one call to get the current space).
What am I missing?
Thanks
-Vincent
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. 
28 Jun
28 Jun
10:40 a.m.
New subject: [xwiki-devs] [VOTE] Add String getCurrentSpace() to DocumentAccessBridge
Vincent Massol wrote:
On Jun 27, 2009, at 2:46 PM, Thomas Mortagne wrote:
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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Sat, Jun 27, 2009 at 10:48, Vincent
Massol<vincent(a)massol.net>
wrote:
I see only 1 getProperty() call for each (and possibly - not even sure
- one call to get the current space).
What am I missing? 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.
1:53 p.m.
On Sun, Jun 28, 2009 at 10:40, Sergiu Dumitriu<sergiu(a)xwiki.com> 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<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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
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.
2:51 p.m.
New subject: [xwiki-devs] [VOTE] Add String getCurrentSpace() to DocumentAccessBridge
Vincent Massol wrote:
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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
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.
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.
2:55 p.m.
New subject: [xwiki-devs] [VOTE] Add String getCurrentSpace() to DocumentAccessBridge
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. 
6:13 p.m.
New subject: [xwiki-devs] Bridge question. Was : [VOTE] Add String getCurrentSpace() to DocumentAccessBridge
On Jun 28, 2009, at 1:53 PM, Thomas Mortagne wrote:
I take advantage of this mail in order to ask for a clarification
about this bridge-related-issues.
The REST subsystem uses the model and the API defined in xwiki-core
and doesn't make use of the bridge at all.
Thomas' argument explains why I did this : since I need access to the
complete XWiki API for exposing it via REST, basically I would have
had to rewrite a "duplicate" of the API in an interface (the bridge)
that is, to my understanding, temporary and that will be discarded
once a new model (and its API) will be available.
However from what Sergiu says I understand that the bridge is there to
stay, so this invalidates my hypothesis.
Since, at some point, we should port the REST subsystem to the "new
thing" that is independent from core, the question is: is the bridge
this "new thing" and we should enrich it to support the complete XWiki
API or we should wait for the new model in order to avoid work that
will be discarded because the bridge is going to disappear as well?
Thanks,
Fabio
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.
6:29 p.m.
New subject: [xwiki-devs] Bridge question. Was : [VOTE] Add String getCurrentSpace() to DocumentAccessBridge
Fabio Mancinelli wrote:
On Jun 28, 2009, at 1:53 PM, Thomas Mortagne wrote:
I take advantage of this mail in order to ask for a clarification
about this bridge-related-issues.
The REST subsystem uses the model and the API defined in xwiki-core
and doesn't make use of the bridge at all.
Thomas' argument explains why I did this : since I need access to the
complete XWiki API for exposing it via REST, basically I would have
had to rewrite a "duplicate" of the API in an interface (the bridge)
that is, to my understanding, temporary and that will be discarded
once a new model (and its API) will be available.
However from what Sergiu says I understand that the bridge is there to
stay, so this invalidates my hypothesis.
Since, at some point, we should port the REST subsystem to the "new
thing" that is independent from core, the question is: is the bridge
this "new thing" and we should enrich it to support the complete XWiki
API or we should wait for the new model in order to avoid work that
will be discarded because the bridge is going to disappear as well?
I tend to agree with Thomas: bridged code is going to be changed anyway,
so for modules that are heavy consumers of the model (like the REST
sub-system), I think bridging is just adding more pain, since in both
cases the whole thing will be refactored with the new model.
For modules that are not heavy consumers of the model, the bridge allows
to not depend on xwiki-core which is desired and more elegant. I still
think they should be refactored with the new model, getting rid of the
bridge.
At least that's how I see it.
Jerome.
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.
Thanks,
Fabio
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
27 Jun
27 Jun
9:27 p.m.
New subject: [xwiki-devs] [VOTE] Add String getCurrentSpace() to DocumentAccessBridge
Vincent Massol 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
+1
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
29 Jun
29 Jun
9:17 p.m.
New subject: [xwiki-devs] [VOTE] Add String getCurrentSpace() to DocumentAccessBridge (CANCELLED)
The vote is cancelled. I don't need this method in the end.
Thanks
-Vincent
On Jun 27, 2009, at 10:48 AM, Vincent Massol 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
Thanks
-Vincent
5558
days inactive
5560
days old
12 comments
5 participants
participants (5)
-
Fabio Mancinelli -
Jerome Velociter -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol