[xwiki-devs] [VOTE] Add String getCurrentSpace() to DocumentAccessBridge
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
On Sat, Jun 27, 2009 at 10:48, Vincent Massol<vincent@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Jun 27, 2009, at 2:46 PM, Thomas Mortagne wrote:
On Sat, Jun 27, 2009 at 10:48, Vincent Massol<vincent@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? 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@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?
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 Sun, Jun 28, 2009 at 10:40, Sergiu Dumitriu<sergiu@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@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Jun 28, 2009, at 1:53 PM, Thomas Mortagne wrote:
On Sun, Jun 28, 2009 at 10:40, Sergiu Dumitriu<sergiu@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@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.
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 28, 2009, at 1:53 PM, Thomas Mortagne wrote: > >> On Sun, Jun 28, 2009 at 10:40, Sergiu Dumitriu<sergiu@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@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. > > 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 Dumitriu http://purl.org/net/sergiu/
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<sergiu@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@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. >> >> 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
Thomas Mortagne wrote: > On Sun, Jun 28, 2009 at 10:40, Sergiu Dumitriu<sergiu@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@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. 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/
On Jun 28, 2009, at 1:53 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.
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.
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
Fabio Mancinelli wrote:
On Jun 28, 2009, at 1:53 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. 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.
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.
Thanks, Fabio _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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/
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
participants (5)
-
Fabio Mancinelli -
Jerome Velociter -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol