Tapestry 5
  1. Tapestry 5
  2. TAP5-64

Support Java Portlet Specification V2 - JSR-286

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 5.0.15
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Specification will be finished early 2008. We need a framework that allows us to write JSR-286 portlets, would be nice if we could stick with T5 for this.

      1. tapestry_portlet_5.0.15.zip
        99 kB
        Tran Le Xuan
      2. tapestry_portlet_5.0.18.zip
        102 kB
        Tran Le Xuan
      3. tapestry_portlet_5.1.0.5.zip
        110 kB
        Tran Le Xuan

        Issue Links

          Activity

          Hide
          François Facon added a comment -

          I'm still working on this jira. this module is already in production and working correctly for 5.2.6, 5.3.7, 5.4.AlphaXX. the build process and testing integration with Pluto works well with Maven. The gradle build is ok but I have not managed to use Tomee Pluto and Arquilian in a gradle build. Any technical feedback is welcome

          Show
          François Facon added a comment - I'm still working on this jira. this module is already in production and working correctly for 5.2.6, 5.3.7, 5.4.AlphaXX. the build process and testing integration with Pluto works well with Maven. The gradle build is ok but I have not managed to use Tomee Pluto and Arquilian in a gradle build. Any technical feedback is welcome
          Hide
          Thiago H. de Paula Figueiredo added a comment -

          In addition, Tapestry does support portlets, but by using a thirdy-party module.

          Show
          Thiago H. de Paula Figueiredo added a comment - In addition, Tapestry does support portlets, but by using a thirdy-party module.
          Hide
          Thiago H. de Paula Figueiredo added a comment -

          What if the Tapestry documentation itself had a "Recommended third-party" modules section? For example, tapestry-security, the integration with Apache Shiro, isn't part of the Tapestry project itself but it's written by a committer of both Tapestry and Shiro and it's widely trusted.

          Latest released Tapestry version is 5.3.6 and tapestry5-portlet says it supports them.

          Show
          Thiago H. de Paula Figueiredo added a comment - What if the Tapestry documentation itself had a "Recommended third-party" modules section? For example, tapestry-security, the integration with Apache Shiro, isn't part of the Tapestry project itself but it's written by a committer of both Tapestry and Shiro and it's widely trusted. Latest released Tapestry version is 5.3.6 and tapestry5-portlet says it supports them.
          Hide
          Pieter Schoenmakers added a comment -

          Inclusion on tapestry.apache.org is like a seal of approval. It provides trust. Provision from somewhere else lacks the seal. It must earn the trust all by itself.

          On the other hand, portlet support from tapestry.apache.org reflects good on tapestry itself. If I were running tapestry, I'd want portlet support in there. All other serious UI frameworks support portlets

          But, we're talking hypotheses here. The attached jars would need to be brought up to par with the latest tap5 before being able to be considered for inclusion.

          Show
          Pieter Schoenmakers added a comment - Inclusion on tapestry.apache.org is like a seal of approval. It provides trust. Provision from somewhere else lacks the seal. It must earn the trust all by itself. On the other hand, portlet support from tapestry.apache.org reflects good on tapestry itself. If I were running tapestry, I'd want portlet support in there. All other serious UI frameworks support portlets But, we're talking hypotheses here. The attached jars would need to be brought up to par with the latest tap5 before being able to be considered for inclusion.
          Hide
          Thiago H. de Paula Figueiredo added a comment -

          Hello, Pieter!

          If tapestry5-portlet is working and if it had its JARs in the Maven Central Respository, would you be satisfied? As I said in the message above, we cannot have too much stuff under the Tapestry project itself because otherwise we wouldn't have the time to support all that.

          Cheers!

          Show
          Thiago H. de Paula Figueiredo added a comment - Hello, Pieter! If tapestry5-portlet is working and if it had its JARs in the Maven Central Respository, would you be satisfied? As I said in the message above, we cannot have too much stuff under the Tapestry project itself because otherwise we wouldn't have the time to support all that. Cheers!
          Hide
          Pieter Schoenmakers added a comment -

          Separate jar is what I'd expect; you don't want to force portlet.jar upon everybody.
          Out of the box, as in documented and provided on tapestry.apache.org just like all tap5 jars.
          (I'm still maintaining a tap4-based portlet app and I would love to migrate to tap5.)

          Show
          Pieter Schoenmakers added a comment - Separate jar is what I'd expect; you don't want to force portlet.jar upon everybody. Out of the box, as in documented and provided on tapestry.apache.org just like all tap5 jars. (I'm still maintaining a tap4-based portlet app and I would love to migrate to tap5.)
          Hide
          Thiago H. de Paula Figueiredo added a comment -

          Hello, Pieter!

          What do you mean by out-of-the-box portlet support? As in tapestry-core itself? I'm sorry, that's not going to happen. Not everybody which uses Tapestry uses portlets, so it doesn't make much sense to put support for it in core. The Tapestry philosophy is to have the basic functionality in tapestry-core and more specific stuff in other JARs, such as tapestry-upload and tapestry-hibernate.

          If it's about a separate JAR under the Apache Tapestry project, tapestry5-portlet is mostly written by Tapestry committers themselves. In addition, we avoid having too much stuff under the Tapestry project itself because we're all volutaries and we'd need to support that code.

          I agree with you that tapestry5-porlet should have its JAR in Maven Central Repository.

          Cheers!

          Show
          Thiago H. de Paula Figueiredo added a comment - Hello, Pieter! What do you mean by out-of-the-box portlet support? As in tapestry-core itself? I'm sorry, that's not going to happen. Not everybody which uses Tapestry uses portlets, so it doesn't make much sense to put support for it in core. The Tapestry philosophy is to have the basic functionality in tapestry-core and more specific stuff in other JARs, such as tapestry-upload and tapestry-hibernate. If it's about a separate JAR under the Apache Tapestry project, tapestry5-portlet is mostly written by Tapestry committers themselves. In addition, we avoid having too much stuff under the Tapestry project itself because we're all volutaries and we'd need to support that code. I agree with you that tapestry5-porlet should have its JAR in Maven Central Repository. Cheers!
          Hide
          Pieter Schoenmakers added a comment -

          I'd expect this issue to be closed once tap5 has out-of-the-box portlet support.
          (PS: I didn't check out the fine work on code or github.)

          Show
          Pieter Schoenmakers added a comment - I'd expect this issue to be closed once tap5 has out-of-the-box portlet support. (PS: I didn't check out the fine work on code or github.)
          Hide
          Thiago H. de Paula Figueiredo added a comment -

          Hi, guys!

          Shouldn't this issue be closed due to the tapestry5-portlet linked above? I haven't used portlets myself, so I'm not the best one to check it.

          If nobody says no in a couple weeks, I'll close this issue.

          Show
          Thiago H. de Paula Figueiredo added a comment - Hi, guys! Shouldn't this issue be closed due to the tapestry5-portlet linked above? I haven't used portlets myself, so I'm not the best one to check it. If nobody says no in a couple weeks, I'll close this issue.
          Hide
          François Facon added a comment -

          Like Felix Scheffer
          (http://code.google.com/p/tapestry5-portlet-support/ for more
          details),
          we have updated the dependencies of this library to use Tapestry 5.2.6.

          This library also support:

          • portlet event processing (JSR 286)
          • serving ajax request as portlet resource (event name that start with
            serve or components declared in the PortletResourceResponseIdentifier
            service)
          • support MARKUP_HEAD_ELEMENT
          • rework on IdAllocator to avoid conflict for generated id when there
            is more than on tapestry portlet in a page.
          • use of Apache Pluto to ease the test

          Code is available at https://github.com/got5/tapestry5-portlet.
          If you want to see it in action, you just need to:

          This bridge is available also in snapshot version for Tapestry 5.3.3.
          To come : documentations and gradle tasks to prepare a clean move to main Tapestry project (Targeted version 5.4)

          Show
          François Facon added a comment - Like Felix Scheffer ( http://code.google.com/p/tapestry5-portlet-support/ for more details), we have updated the dependencies of this library to use Tapestry 5.2.6. This library also support: portlet event processing (JSR 286) serving ajax request as portlet resource (event name that start with serve or components declared in the PortletResourceResponseIdentifier service) support MARKUP_HEAD_ELEMENT rework on IdAllocator to avoid conflict for generated id when there is more than on tapestry portlet in a page. use of Apache Pluto to ease the test Code is available at https://github.com/got5/tapestry5-portlet . If you want to see it in action, you just need to: Download the sources Go to the repository directory Run "mvn jetty:run" Open your browser to http://localhost:8080/tapestry5-portlet/portal/Index This bridge is available also in snapshot version for Tapestry 5.3.3. To come : documentations and gradle tasks to prepare a clean move to main Tapestry project (Targeted version 5.4)
          Hide
          Patrick Cornelißen added a comment -

          Due to the raising adoption of portal servers like liferay in for example Germany, I see a definitive need for portlet support in the major frameworks. I have encountered quite a few projects that had to be ported from servlet to portlet and when the framework has no support, you have to rewrite almost the whole app. I don't think that this helps tapestry if the devs simply ignore that.
          I for myself won't use tapestry for a coming project, because I know that it needs to run in a portal server later...

          Just my 2c

          Show
          Patrick Cornelißen added a comment - Due to the raising adoption of portal servers like liferay in for example Germany, I see a definitive need for portlet support in the major frameworks. I have encountered quite a few projects that had to be ported from servlet to portlet and when the framework has no support, you have to rewrite almost the whole app. I don't think that this helps tapestry if the devs simply ignore that. I for myself won't use tapestry for a coming project, because I know that it needs to run in a portal server later... Just my 2c
          Hide
          François Facon added a comment -

          we have an ongoing study on this subject based on Makus work.

          Show
          François Facon added a comment - we have an ongoing study on this subject based on Makus work.
          Hide
          postmaster@cumquat added a comment -

          Beste afzender,

          Dit e-mailadres van Cumquat is niet langer meer in gebruik. U kunt
          contact opnemen met Cumquat via een van de onderstaande
          e-mailadressen:

          • project.office@cumquat.nl voor projectgerelateerde onderwerpen
          • sales@cumquat.nl voor commerciële onderwerpen
          • info@cumquat.nl voor algemene onderwerpen

          Dank u wel.

          Dear sender,

          This e-mail account of Cumquat is no longer is use. Please contact
          Cumquat by using one of the e-mail accounts below:

          • project.office@cumquat.nl for project related issues
          • sales@cumquat.nl for sales questions
          • info@cumquat.nl for general questions

          Thank you.

          Cumquat Information Technology B.V.
          De Dreef 19
          3706 BR ZEIST
          t +31 (0)30 6940 490
          f +31 (0)30 6940 499
          i www.cumquat.nl

          Show
          postmaster@cumquat added a comment - Beste afzender, Dit e-mailadres van Cumquat is niet langer meer in gebruik. U kunt contact opnemen met Cumquat via een van de onderstaande e-mailadressen: project.office@cumquat.nl voor projectgerelateerde onderwerpen sales@cumquat.nl voor commerciële onderwerpen info@cumquat.nl voor algemene onderwerpen Dank u wel. Dear sender, This e-mail account of Cumquat is no longer is use. Please contact Cumquat by using one of the e-mail accounts below: project.office@cumquat.nl for project related issues sales@cumquat.nl for sales questions info@cumquat.nl for general questions Thank you. Cumquat Information Technology B.V. De Dreef 19 3706 BR ZEIST t +31 (0)30 6940 490 f +31 (0)30 6940 499 i www.cumquat.nl
          Hide
          Massimo Lusetti added a comment -

          Does this still current and with interested?

          Show
          Massimo Lusetti added a comment - Does this still current and with interested?
          Hide
          Markus Feindler added a comment -

          Hey, I have extended the code of Tran Le Xuan and Kristina B. Taylor. XHR Requests and Resource Serving has been implemented.
          Check details on my google code project: http://code.google.com/p/tapestry5portlet/

          Show
          Markus Feindler added a comment - Hey, I have extended the code of Tran Le Xuan and Kristina B. Taylor. XHR Requests and Resource Serving has been implemented. Check details on my google code project: http://code.google.com/p/tapestry5portlet/
          Hide
          Marcus added a comment -

          Due the new portal features in JSR-286 (events, resource serving (ajax), filters, policy, public render parameters), don't you think that Portlet2 deserves a separate version of Tapestry? There is a gap in this area.

          Show
          Marcus added a comment - Due the new portal features in JSR-286 (events, resource serving (ajax), filters, policy, public render parameters), don't you think that Portlet2 deserves a separate version of Tapestry? There is a gap in this area.
          Hide
          Tran Le Xuan added a comment - - edited

          This is my contribution for supporting tapestry runs in portlet mode. I develop from the source of Kristina B. Taylor (https://issues.apache.org/jira/browse/TAP5-78). Thanks for Kristina. The source now supports tapestry versions from 5.0.15 to 5.0.18, and 5.1.0.5.
          For version 5.0.15, I fixed the bug about the action event and the passivate context from Kristina source.
          For version 5.0.18, it can run with tapestry version 5.0.16, 5.0.17, and 5.0.18.

          Show
          Tran Le Xuan added a comment - - edited This is my contribution for supporting tapestry runs in portlet mode. I develop from the source of Kristina B. Taylor ( https://issues.apache.org/jira/browse/TAP5-78 ). Thanks for Kristina. The source now supports tapestry versions from 5.0.15 to 5.0.18, and 5.1.0.5. For version 5.0.15, I fixed the bug about the action event and the passivate context from Kristina source. For version 5.0.18, it can run with tapestry version 5.0.16, 5.0.17, and 5.0.18.
          Hide
          Jesse Kuhnert added a comment -

          I just don't think you understand how open source works Jan.

          If it was really that important then you should:

          a) Make a go of portlet support yourself.
          b) Have your company pay Howard to do it.

          The source is right there, so anyone can in theory jump right in and do it. That's how it works.

          Show
          Jesse Kuhnert added a comment - I just don't think you understand how open source works Jan. If it was really that important then you should: a) Make a go of portlet support yourself. b) Have your company pay Howard to do it. The source is right there, so anyone can in theory jump right in and do it. That's how it works.
          Hide
          Jan Vissers added a comment -

          OMG Jesse - you are doing the Tapestry community a bad favor reacting the way you do.

          Just to make myself perfectly clear. I don't want to go to Wicket and/or JSF, because I love working in Tapestry. I'm personally responsible for the adoption of Tapestry at my company (from version 3.0). I just want to point out that Tapestry 5 will even be more appealing to use, when we can use it to create our portlets.

          Show
          Jan Vissers added a comment - OMG Jesse - you are doing the Tapestry community a bad favor reacting the way you do. Just to make myself perfectly clear. I don't want to go to Wicket and/or JSF, because I love working in Tapestry. I'm personally responsible for the adoption of Tapestry at my company (from version 3.0). I just want to point out that Tapestry 5 will even be more appealing to use, when we can use it to create our portlets.
          Hide
          Jesse Kuhnert added a comment -

          Why don't you just go use wicket then Jan? I don't think anyone here really cares what you use.

          Show
          Jesse Kuhnert added a comment - Why don't you just go use wicket then Jan? I don't think anyone here really cares what you use.
          Hide
          Jan Vissers added a comment -

          FYI: final spec approved - http://jcp.org/en/jsr/detail?id=286

          JSR-301 will specify how JSF can be bridged for JSR-286.
          Work is well underway for Wicket 1.4 to allow JSR-286 portlet development.

          Show
          Jan Vissers added a comment - FYI: final spec approved - http://jcp.org/en/jsr/detail?id=286 JSR-301 will specify how JSF can be bridged for JSR-286. Work is well underway for Wicket 1.4 to allow JSR-286 portlet development.

            People

            • Assignee:
              François Facon
              Reporter:
              Jan Vissers
            • Votes:
              20 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:

                Development