14 Jun
2010
14 Jun
'10
6:14 p.m.
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
14 Jun
14 Jun
6:19 p.m.
+1
On Mon, Jun 14, 2010 at 18:14, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
6:25 p.m.
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
6:29 p.m.
On Jun 14, 2010, at 6:25 PM, Vincent Massol wrote:
On Jun 14, 2010, at 6:14 PM, Marius Dumitru Florea wrote:
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 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.
15 Jun
15 Jun
9:52 a.m.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:19 a.m.
On Jun 15, 2010, at 9:52 AM, Marius Dumitru Florea wrote:
Hi Vincent,
On 06/14/2010 07:29 PM, Vincent Massol wrote:
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#HOverviewofth…
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.
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).
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
>
> 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
10:31 a.m.
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#HOverviewofth…
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-Coup…
. 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
10:36 a.m.
On Jun 15, 2010, at 10:31 AM, Marius Dumitru Florea wrote:
On 06/15/2010 11:19 AM, Vincent Massol wrote:
oh :) I understand now.
Thanks
-Vincent
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#HOverviewofth…
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-Coup…
. 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 
14 Jun
14 Jun
6:26 p.m.
+0,
JV.
On Mon, Jun 14, 2010 at 6:14 PM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:16 p.m.
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5207
days inactive
5208
days old
9 comments
5 participants
participants (5)
-
Jean-Vincent Drean -
Jerome Velociter -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol