[xwiki-devs] [Proposal] XWiki Portlet Integration
Hi devs, You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration. We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2. For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though. WDYT? Thanks, Marius
+1 On Mon, Jun 14, 2010 at 18:14, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Jun 14, 2010, at 6:14 PM, Marius Dumitru Florea wrote:
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
I'd like to see how it integrates with the portlet module in containers. I don't think it's a good idea to have 2 places for portlets at the same time. I'd also like to see how it integrates in container/ module in general. We have defined a place for environments in containers/ so if you're proposing to put code outside of it, it means this container notion doesn't work and we need to get rid of it. Thanks -Vincent
On Jun 14, 2010, at 6:25 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:14 PM, Marius Dumitru Florea wrote:
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
I'd like to see how it integrates with the portlet module in containers. I don't think it's a good idea to have 2 places for portlets at the same time. I'd also like to see how it integrates in container/ module in general.
We have defined a place for environments in containers/ so if you're proposing to put code outside of it, it means this container notion doesn't work and we need to get rid of it.
hmm what you are saying I think is that your implementation is an implementation using old concepts (ie xwiki-core). So far everything that was done the old way has been put in xwiki-core (and in plugins). I'd prefer to isolate new stuff from old stuff that has to go away. So it seems we'd need something like: platform/xwiki-old/ |_ xwiki-core/ |_ xwiki-portlet Do I understand correctly? Thanks -Vincent
Hi Vincent, On 06/14/2010 07:29 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:25 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:14 PM, Marius Dumitru Florea wrote:
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
I'd like to see how it integrates with the portlet module in containers. I don't think it's a good idea to have 2 places for portlets at the same time. I'd also like to see how it integrates in container/ module in general.
The loosely-coupled integration solution works with _any_ servlet application that: * is hosted on the same server as the portlet * runs in the same application context as the portlet (e.g. /xwiki) * and uses a single entry point servlet (e.g. /bin). The code in sandbox/xwiki-portlet is generic and so it doesn't know of any container module XWiki (i.e. the servlet application) may be using. It's a bridge between the portlet world and the servlet world. It exposes a servlet application as a portlet. I'd like to keep the part that is XWiki specific only in configuration (e.g. urlmapping.cfg).
We have defined a place for environments in containers/ so if you're proposing to put code outside of it, it means this container notion doesn't work and we need to get rid of it.
I looked at the code in xwiki-container-api module and my impression is that it defines interfaces that mimic the servlet model. I don't think it will work well with other models like portlet that have multiple request types, multiple URL types, a different life cycle, etc. The code in xwiki-container-api is supposed to be abstract but it is clearly following the servlet specification, which is not surprising because XWiki was developed as a servlet application. It's not enough to hide container specific objects like request and response behind an interface, there will be for sure container dependent code due to life cycle differences. As a consequence the container module becomes a bottle neck between the container specific objects and container dependent code that needs to use these objects.
hmm what you are saying I think is that your implementation is an implementation using old concepts (ie xwiki-core).
No, it has no dependency on xwiki-core.
So far everything that was done the old way has been put in xwiki-core (and in plugins).
I'd prefer to isolate new stuff from old stuff that has to go away. So it seems we'd need something like:
platform/xwiki-old/ |_ xwiki-core/ |_ xwiki-portlet
Do I understand correctly?
No. As I said, the code in sandbox/xwiki-portlet is generic so I don't think it should be placed under a xwiki-old parent. It has nothing to do with the old xwiki core. Thanks, Marius
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 15, 2010, at 9:52 AM, Marius Dumitru Florea wrote:
Hi Vincent,
On 06/14/2010 07:29 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:25 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:14 PM, Marius Dumitru Florea wrote:
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
I'd like to see how it integrates with the portlet module in containers. I don't think it's a good idea to have 2 places for portlets at the same time. I'd also like to see how it integrates in container/ module in general.
The loosely-coupled integration solution works with _any_ servlet application that:
* is hosted on the same server as the portlet * runs in the same application context as the portlet (e.g. /xwiki) * and uses a single entry point servlet (e.g. /bin).
The code in sandbox/xwiki-portlet is generic and so it doesn't know of any container module XWiki (i.e. the servlet application) may be using. It's a bridge between the portlet world and the servlet world. It exposes a servlet application as a portlet.
ok. I must have misread the doc you wrote somehow.... In the section "Overview of the Current Implementation" on http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration#HOverviewofthe... it says: * "tightly-coupled with xwiki-core" * "XWikiPortlet duplicates code from XWikiAction" * "XWikiPortletURLFactory" These are all statements that made me think it was depending tightly on xwiki-core.
I'd like to keep the part that is XWiki specific only in configuration (e.g. urlmapping.cfg).
We have defined a place for environments in containers/ so if you're proposing to put code outside of it, it means this container notion doesn't work and we need to get rid of it.
I looked at the code in xwiki-container-api module and my impression is that it defines interfaces that mimic the servlet model. I don't think it will work well with other models like portlet that have multiple request types, multiple URL types, a different life cycle, etc. The code in xwiki-container-api is supposed to be abstract but it is clearly following the servlet specification, which is not surprising because XWiki was developed as a servlet application.
It's not enough to hide container specific objects like request and response behind an interface, there will be for sure container dependent code due to life cycle differences. As a consequence the container module becomes a bottle neck between the container specific objects and container dependent code that needs to use these objects.
Well your module proves the opposite since it's built on top of Servlets ;) Obviously it must have some limitations (which are they?). Is that what you mean by won't work? The goal of the container module is to have code that is executed after it be independent of the container in which they execute (for most cases, there are cases when it' not possible and in theses cases these modules will work only in a given container). But for example the notion of ApplicationContext is very important since it allows to access resource present in the environment. We need to understand better what won't work with the container module. Maybe the best is to start with use cases and see how we could make it work within these use cases? We need to prove it won't work and decide what to do before we ditch it. Of course I'd prefer if we can find a way to make it work. Thanks -Vincent
hmm what you are saying I think is that your implementation is an implementation using old concepts (ie xwiki-core).
No, it has no dependency on xwiki-core.
So far everything that was done the old way has been put in xwiki-core (and in plugins).
I'd prefer to isolate new stuff from old stuff that has to go away. So it seems we'd need something like:
platform/xwiki-old/ |_ xwiki-core/ |_ xwiki-portlet
Do I understand correctly?
No. As I said, the code in sandbox/xwiki-portlet is generic so I don't think it should be placed under a xwiki-old parent. It has nothing to do with the old xwiki core.
Thanks, Marius
On 06/15/2010 11:19 AM, Vincent Massol wrote:
On Jun 15, 2010, at 9:52 AM, Marius Dumitru Florea wrote:
Hi Vincent,
On 06/14/2010 07:29 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:25 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:14 PM, Marius Dumitru Florea wrote:
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
I'd like to see how it integrates with the portlet module in containers. I don't think it's a good idea to have 2 places for portlets at the same time. I'd also like to see how it integrates in container/ module in general.
The loosely-coupled integration solution works with _any_ servlet application that:
* is hosted on the same server as the portlet * runs in the same application context as the portlet (e.g. /xwiki) * and uses a single entry point servlet (e.g. /bin).
The code in sandbox/xwiki-portlet is generic and so it doesn't know of any container module XWiki (i.e. the servlet application) may be using. It's a bridge between the portlet world and the servlet world. It exposes a servlet application as a portlet.
ok. I must have misread the doc you wrote somehow.... In the section "Overview of the Current Implementation" on http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration#HOverviewofthe... it says:
* "tightly-coupled with xwiki-core" * "XWikiPortlet duplicates code from XWikiAction" * "XWikiPortletURLFactory"
These are all statements that made me think it was depending tightly on xwiki-core.
My bad. I should have said "Overview of the Current Implementation in XWiki Core". This section describes the old code from xwiki-core that handles the integration with Java Portlet Specification 1.0. The code in sandbox/xwiki-portlet is described in http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration#HLoosely-Coupl... . I'll fix the draft.
I'd like to keep the part that is XWiki specific only in configuration (e.g. urlmapping.cfg).
We have defined a place for environments in containers/ so if you're proposing to put code outside of it, it means this container notion doesn't work and we need to get rid of it.
I looked at the code in xwiki-container-api module and my impression is that it defines interfaces that mimic the servlet model. I don't think it will work well with other models like portlet that have multiple request types, multiple URL types, a different life cycle, etc. The code in xwiki-container-api is supposed to be abstract but it is clearly following the servlet specification, which is not surprising because XWiki was developed as a servlet application.
It's not enough to hide container specific objects like request and response behind an interface, there will be for sure container dependent code due to life cycle differences. As a consequence the container module becomes a bottle neck between the container specific objects and container dependent code that needs to use these objects.
Well your module proves the opposite since it's built on top of Servlets ;)
Obviously it must have some limitations (which are they?). Is that what you mean by won't work?
The goal of the container module is to have code that is executed after it be independent of the container in which they execute (for most cases, there are cases when it' not possible and in theses cases these modules will work only in a given container). But for example the notion of ApplicationContext is very important since it allows to access resource present in the environment.
We need to understand better what won't work with the container module. Maybe the best is to start with use cases and see how we could make it work within these use cases?
We need to prove it won't work and decide what to do before we ditch it. Of course I'd prefer if we can find a way to make it work.
I'll comment on this asap. Thanks, Marius
Thanks -Vincent
hmm what you are saying I think is that your implementation is an implementation using old concepts (ie xwiki-core).
No, it has no dependency on xwiki-core.
So far everything that was done the old way has been put in xwiki-core (and in plugins).
I'd prefer to isolate new stuff from old stuff that has to go away. So it seems we'd need something like:
platform/xwiki-old/ |_ xwiki-core/ |_ xwiki-portlet
Do I understand correctly?
No. As I said, the code in sandbox/xwiki-portlet is generic so I don't think it should be placed under a xwiki-old parent. It has nothing to do with the old xwiki core.
Thanks, Marius
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jun 15, 2010, at 10:31 AM, Marius Dumitru Florea wrote:
On 06/15/2010 11:19 AM, Vincent Massol wrote:
On Jun 15, 2010, at 9:52 AM, Marius Dumitru Florea wrote:
Hi Vincent,
On 06/14/2010 07:29 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:25 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:14 PM, Marius Dumitru Florea wrote:
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
I'd like to see how it integrates with the portlet module in containers. I don't think it's a good idea to have 2 places for portlets at the same time. I'd also like to see how it integrates in container/ module in general.
The loosely-coupled integration solution works with _any_ servlet application that:
* is hosted on the same server as the portlet * runs in the same application context as the portlet (e.g. /xwiki) * and uses a single entry point servlet (e.g. /bin).
The code in sandbox/xwiki-portlet is generic and so it doesn't know of any container module XWiki (i.e. the servlet application) may be using. It's a bridge between the portlet world and the servlet world. It exposes a servlet application as a portlet.
ok. I must have misread the doc you wrote somehow.... In the section "Overview of the Current Implementation" on http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration#HOverviewofthe... it says:
* "tightly-coupled with xwiki-core" * "XWikiPortlet duplicates code from XWikiAction" * "XWikiPortletURLFactory"
These are all statements that made me think it was depending tightly on xwiki-core.
My bad. I should have said "Overview of the Current Implementation in XWiki Core". This section describes the old code from xwiki-core that handles the integration with Java Portlet Specification 1.0. The code in sandbox/xwiki-portlet is described in http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration#HLoosely-Coupl... . I'll fix the draft.
oh :) I understand now. Thanks -Vincent
I'd like to keep the part that is XWiki specific only in configuration (e.g. urlmapping.cfg).
We have defined a place for environments in containers/ so if you're proposing to put code outside of it, it means this container notion doesn't work and we need to get rid of it.
I looked at the code in xwiki-container-api module and my impression is that it defines interfaces that mimic the servlet model. I don't think it will work well with other models like portlet that have multiple request types, multiple URL types, a different life cycle, etc. The code in xwiki-container-api is supposed to be abstract but it is clearly following the servlet specification, which is not surprising because XWiki was developed as a servlet application.
It's not enough to hide container specific objects like request and response behind an interface, there will be for sure container dependent code due to life cycle differences. As a consequence the container module becomes a bottle neck between the container specific objects and container dependent code that needs to use these objects.
Well your module proves the opposite since it's built on top of Servlets ;)
Obviously it must have some limitations (which are they?). Is that what you mean by won't work?
The goal of the container module is to have code that is executed after it be independent of the container in which they execute (for most cases, there are cases when it' not possible and in theses cases these modules will work only in a given container). But for example the notion of ApplicationContext is very important since it allows to access resource present in the environment.
We need to understand better what won't work with the container module. Maybe the best is to start with use cases and see how we could make it work within these use cases?
We need to prove it won't work and decide what to do before we ditch it. Of course I'd prefer if we can find a way to make it work.
I'll comment on this asap.
Thanks, Marius
Thanks -Vincent
hmm what you are saying I think is that your implementation is an implementation using old concepts (ie xwiki-core).
No, it has no dependency on xwiki-core.
So far everything that was done the old way has been put in xwiki-core (and in plugins).
I'd prefer to isolate new stuff from old stuff that has to go away. So it seems we'd need something like:
platform/xwiki-old/ |_ xwiki-core/ |_ xwiki-portlet
Do I understand correctly?
No. As I said, the code in sandbox/xwiki-portlet is generic so I don't think it should be placed under a xwiki-old parent. It has nothing to do with the old xwiki core.
Thanks, Marius
+0, JV. On Mon, Jun 14, 2010 at 6:14 PM, Marius Dumitru Florea <[email protected]> wrote:
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 for replacing the legacy portlet integration by your new xwiki-portlet modul, until we decide for a long term strategy re the container module. We would need to fix the issues relative to URL in AJAX response (livetable, etc.) before 2.4 final. Could be interesting to create a distribution for this portlet integration. For example, based on http://www.jboss.org/gatein/portletcontainer.html. It could be used for running some integration tests as well. One last thing, and probably the most important, is that we need to think how the XWiki UI should be envisaged when running in portlet, in terms of menus, styles, configuration (shared settings), etc. We should open a separate design discussion on this topic. Jerome.
Hi devs,
You can find here http://dev.xwiki.org/xwiki/bin/view/Drafts/PortletIntegration a draft regarding the portlet integration.
We need to decide what's the best approach. For short term I think the loosely-coupled integration solution is the best as it requires less changes to the core. The current implementation is in http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-portlet/ and I propose to move it to platform/xwiki-portlet before 2.4M2.
For long term, when we'll have the new model in place, we might consider the tightly-coupled integration solution as it seems to be more clean and it follows the component way. It won't be easy to implement though.
WDYT?
Thanks, Marius _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (5)
-
Jean-Vincent Drean -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol