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#HOverviewoftheCurrentImplementation > 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-Coupled . 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
