Hi, I´m part of a development team that is trying to get XWIKI working as a jsr168 portlet, to integrate it in a commercial portal. We have been able to run it on Jetspeed-2 without major problems, except for URLs. It seems that Portlet URLs are generated and then filtered that causes some major bugs in urls within the portlet since a url ending with 2 underscores ( ..../...__/ ). Has this problem been submitted before? I´ve looked in Jira but didn´t found nothing related to it. Is there any information on where to start digging or changes adviced, without changing the normal flow of xwiki? What should/must be done, if possible, to integrate the xwiki to that commercial portal, according to your requirements? Another issue is that any changes to XWiki Core must be delivered to the project according to the License, is that valid also for skins developed? Thanks in advance Ricardo Esquito. ps -> sorry for the bad english :-s
Ricardo, We too are working on the same project. We need a JSR168 portlet. Why not share your code with the XWiki project and we can all work on fixing these problems. From our perspective the main difficulty is building a portlet whose HTML structure is neutral enough to allow the container's style-sheet to work. We want to deploy a Wiki portlet in multiple JSR168 containers and we want the container's look and feel to come through without need to change the portlet. I feel this is a problem with XWiki in general. The Velocity macro's include much of the logic and the HTML/CSS. To make the XWiki's skin match another system, I need to modify many VM files. This is ok, but each time I upgrade XWiki I must redo the work. We are building portlet code that make a clearer separation of code from HTML as this should reduce the portlet's maintenance when new versions of XWiki are released. Ian Ricardo Esquito wrote:
Hi,
I�m part of a development team that is trying to get XWIKI working as a jsr168 portlet, to integrate it in a commercial portal. We have been able to run it on Jetspeed-2 without major problems, except for URLs. It seems that Portlet URLs are generated and then filtered that causes some major bugs in urls within the portlet since a url ending with 2 underscores ( ..../...__/ ). Has this problem been submitted before? I�ve looked in Jira but didn�t found nothing related to it. Is there any information on where to start digging or changes adviced, without changing the normal flow of xwiki?
What should/must be done, if possible, to integrate the xwiki to that commercial portal, according to your requirements?
Another issue is that any changes to XWiki Core must be delivered to the project according to the License, is that valid also for skins developed?
Thanks in advance
Ricardo Esquito.
ps -> sorry for the bad english :-s
-- Certus Technology Associates Limited. http://www.certus-tech.com Tel: +44 (0)1392 270930
Hi Ian, Thank you for your answer and sorry for taking so long to aswer. After some "thinking" we decided to develop a new skin from scratch, because of the project scheduling and some specific client requirements. Altough, just like you said in your aswer "... I upgrade XWiki I must redo the work...", this may bring some minor issues, we think that´s the best path to follow at this moment. We were able to deploy XWiki to Jetspeed and Vignette ( under Weblogic 8.1 ) using SqlServer with only a few changes in configuration files. Ricardo Ian Bamsey escreveu:
Ricardo,
We too are working on the same project. We need a JSR168 portlet. Why not share your code with the XWiki project and we can all work on fixing these problems. From our perspective the main difficulty is building a portlet whose HTML structure is neutral enough to allow the container's style-sheet to work. We want to deploy a Wiki portlet in multiple JSR168 containers and we want the container's look and feel to come through without need to change the portlet.
I feel this is a problem with XWiki in general. The Velocity macro's include much of the logic and the HTML/CSS. To make the XWiki's skin match another system, I need to modify many VM files. This is ok, but each time I upgrade XWiki I must redo the work. We are building portlet code that make a clearer separation of code from HTML as this should reduce the portlet's maintenance when new versions of XWiki are released.
Ian
Ricardo Esquito wrote:
Hi,
I�m part of a development team that is trying to get XWIKI working as a jsr168 portlet, to integrate it in a commercial portal. We have been able to run it on Jetspeed-2 without major problems, except for URLs. It seems that Portlet URLs are generated and then filtered that causes some major bugs in urls within the portlet since a url ending with 2 underscores ( ..../...__/ ). Has this problem been submitted before? I�ve looked in Jira but didn�t found nothing related to it. Is there any information on where to start digging or changes adviced, without changing the normal flow of xwiki?
What should/must be done, if possible, to integrate the xwiki to that commercial portal, according to your requirements?
Another issue is that any changes to XWiki Core must be delivered to the project according to the License, is that valid also for skins developed?
Thanks in advance
Ricardo Esquito.
ps -> sorry for the bad english :-s
Ricardo, Thanks for the reply. We are going down a similar path. I'd be interested in your approach. When you say you're able to deploy with only a few changes, do you mean changes to your portal/portlet config, or do you mean you've been able to deploy XWiki as a portlet with only a few config changes? If so, please outline what do did. Many thanks, Ian Ricardo Esquito wrote:
Hi Ian,
Thank you for your answer and sorry for taking so long to aswer.
After some "thinking" we decided to develop a new skin from scratch, because of the project scheduling and some specific client requirements. Altough, just like you said in your aswer "... I upgrade XWiki I must redo the work...", this may bring some minor issues, we think that´s the best path to follow at this moment. We were able to deploy XWiki to Jetspeed and Vignette ( under Weblogic 8.1 ) using SqlServer with only a few changes in configuration files.
Ricardo
Ian Bamsey escreveu:
Ricardo,
We too are working on the same project. We need a JSR168 portlet. Why not share your code with the XWiki project and we can all work on fixing these problems. From our perspective the main difficulty is building a portlet whose HTML structure is neutral enough to allow the container's style-sheet to work. We want to deploy a Wiki portlet in multiple JSR168 containers and we want the container's look and feel to come through without need to change the portlet.
I feel this is a problem with XWiki in general. The Velocity macro's include much of the logic and the HTML/CSS. To make the XWiki's skin match another system, I need to modify many VM files. This is ok, but each time I upgrade XWiki I must redo the work. We are building portlet code that make a clearer separation of code from HTML as this should reduce the portlet's maintenance when new versions of XWiki are released.
Ian
Ricardo Esquito wrote:
Hi,
I�m part of a development team that is trying to get XWIKI working as a jsr168 portlet, to integrate it in a commercial portal. We have been able to run it on Jetspeed-2 without major problems, except for URLs. It seems that Portlet URLs are generated and then filtered that causes some major bugs in urls within the portlet since a url ending with 2 underscores ( ..../...__/ ). Has this problem been submitted before? I�ve looked in Jira but didn�t found nothing related to it. Is there any information on where to start digging or changes adviced, without changing the normal flow of xwiki?
What should/must be done, if possible, to integrate the xwiki to that commercial portal, according to your requirements?
Another issue is that any changes to XWiki Core must be delivered to the project according to the License, is that valid also for skins developed?
Thanks in advance
Ricardo Esquito.
ps -> sorry for the bad english :-s
-- Certus Technology Associates Limited. http://www.certus-tech.com Tel: +44 (0)1392 270930
participants (2)
-
Ian Bamsey -
Ricardo Esquito