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