15 Jun
2010
15 Jun
'10
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