Wicket
  1. Wicket
  2. WICKET-647 New Wicket Portlet support
  3. WICKET-657

New Wicket Portlet support: adapting wicket-examples to use the new portlet support so they can be run as portlets

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.0-beta2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Activity

      Hide
      Ate Douma added a comment -

      Done for now

      Show
      Ate Douma added a comment - Done for now
      Hide
      Ate Douma added a comment -

      NB: Even if the new WicketExamplesMenuApplication/Portlet is capable of showing off all other Wicket Examples from one Portlet Window, those other examples still can be run individually as portlets too!

      Show
      Ate Douma added a comment - NB: Even if the new WicketExamplesMenuApplication/Portlet is capable of showing off all other Wicket Examples from one Portlet Window, those other examples still can be run individually as portlets too!
      Hide
      Ate Douma added a comment -

      With the latest changes and additions to the wicket core, all Wicket Examples can be run as a portlet except for the frames and prototype example.
      And several initial changes have even been reverted!
      The most important (and mostly only) change to Wicket Examples is the required upgrade to Servlet api 2.4 to allow the WicketFilter to work on RequestDispatcher include as required for portlets.

      Additionally, I've written a new example, WicketExamplesMenuApplication which is a portlet context only Wicket example.
      It is served by WicketExamplesMenuPortlet which extends WicketPortlet to "wrap" the available (Wicket) portlets in the war with a front-end menu, just like the static index.html start page in a Servlet environment.

      But this MenuPortlet is quite a bit more fancy
      It dynamically determines the available portlets by parsing portlet.xml and build its menu from it and renders it through a Wicket MenuPage.
      Furthermore, it has 2 other Wicket Pages: HeaderPage and EditPage.

      When one of the menu items is selected, the MenuPortlet will first invoke the WicketExamplesMenuApplication to render the HeaderPage. This page provides a back link to the main MenuPage.
      Then, the MenuPortlet invokes the selected Wicket Example and renders it within its own portlet window!
      So, effectively, this gives the same appearance and behavior as what the normal Servlet based WicketExampleHeader does.
      But, to prevent that header back link from rendering (which links to the static index.html) in a portlet context, I've modified WicketExampleHeader slightly to make that link invisible in that case.
      When rendered as a normal Servlet example, the behavior hasn't changed.

      Finally, the MenuPortlet also provides a PortletMode.EDIT page, EditPage, which can be invoked from the Portlet window action icons (most left icon in the top right corner).
      When the EditPage is rendered, it allows the user to select the default example to be displayed in VIEW mode.
      This is initially the MenuPage showing all available examples, but when one of the other examples is chosen, this will be stored as Portlet Preference (thus persisted for this user),
      after which it will automatically switch back the VIEW mode and the selected example is displayed.
      The next time you open the portal page (like after stopping the portal or logging out), you'll notice the selected example now is displayed by default.

      Show
      Ate Douma added a comment - With the latest changes and additions to the wicket core, all Wicket Examples can be run as a portlet except for the frames and prototype example. And several initial changes have even been reverted! The most important (and mostly only) change to Wicket Examples is the required upgrade to Servlet api 2.4 to allow the WicketFilter to work on RequestDispatcher include as required for portlets. Additionally, I've written a new example, WicketExamplesMenuApplication which is a portlet context only Wicket example. It is served by WicketExamplesMenuPortlet which extends WicketPortlet to "wrap" the available (Wicket) portlets in the war with a front-end menu, just like the static index.html start page in a Servlet environment. But this MenuPortlet is quite a bit more fancy It dynamically determines the available portlets by parsing portlet.xml and build its menu from it and renders it through a Wicket MenuPage. Furthermore, it has 2 other Wicket Pages: HeaderPage and EditPage. When one of the menu items is selected, the MenuPortlet will first invoke the WicketExamplesMenuApplication to render the HeaderPage. This page provides a back link to the main MenuPage. Then, the MenuPortlet invokes the selected Wicket Example and renders it within its own portlet window! So, effectively, this gives the same appearance and behavior as what the normal Servlet based WicketExampleHeader does. But, to prevent that header back link from rendering (which links to the static index.html) in a portlet context, I've modified WicketExampleHeader slightly to make that link invisible in that case. When rendered as a normal Servlet example, the behavior hasn't changed. Finally, the MenuPortlet also provides a PortletMode.EDIT page, EditPage, which can be invoked from the Portlet window action icons (most left icon in the top right corner). When the EditPage is rendered, it allows the user to select the default example to be displayed in VIEW mode. This is initially the MenuPage showing all available examples, but when one of the other examples is chosen, this will be stored as Portlet Preference (thus persisted for this user), after which it will automatically switch back the VIEW mode and the selected example is displayed. The next time you open the portal page (like after stopping the portal or logging out), you'll notice the selected example now is displayed by default.
      Hide
      Ate Douma added a comment -

      Switching to a new 1.3.0-beta3-portlet-support branch

      Show
      Ate Douma added a comment - Switching to a new 1.3.0-beta3-portlet-support branch
      Hide
      Ate Douma added a comment -

      I've adapted the wicket-examples to support running as portlets by:

      • upgrading web.xml to the servlet api 2.4
      • replacing WicketFilter by WicketPortletFilter in web.xml
      • configuring Jetspeed-2 specific implementations for the required org.apache.portals.bridges.common.ServletContextProvider and org.apache.portals.bridges.common.PortletResourceURLFactory interfaces in web.xml
      • added a dependency on the portlet-api-1.0 (note: this one is to be "provided" by portals)
      • adding a portlet.xml providing WicketPortlet instances mapped to WicketPortletFilter paths in web.xml

      That's it.

      The wicket-examples can still be accessed directly as plain web application, but also (at the same time) as portlets

      Note: not all examples do work, although the majority does.
      For some of the examples this is understandable like with the FramesApplication which I think never can be run in a portal.
      And the same goes for the link to the source code provided in every example.

      But the Ajax Debug Window works quite nicely, as most of the Ajax examples.
      I'd anyone interested to try it out themselves, I definitely need feedback and review on all of this.

      To help out with testing, I'm going to provide a custom jetspeed-2.1.1-wicket-installer.jar with all wicket portlets already installed and accessible through the Jetspeed-2 page menus.
      That's going to be the next subtask/issue.

      Show
      Ate Douma added a comment - I've adapted the wicket-examples to support running as portlets by: upgrading web.xml to the servlet api 2.4 replacing WicketFilter by WicketPortletFilter in web.xml configuring Jetspeed-2 specific implementations for the required org.apache.portals.bridges.common.ServletContextProvider and org.apache.portals.bridges.common.PortletResourceURLFactory interfaces in web.xml added a dependency on the portlet-api-1.0 (note: this one is to be "provided" by portals) adding a portlet.xml providing WicketPortlet instances mapped to WicketPortletFilter paths in web.xml That's it. The wicket-examples can still be accessed directly as plain web application, but also (at the same time) as portlets Note: not all examples do work, although the majority does. For some of the examples this is understandable like with the FramesApplication which I think never can be run in a portal. And the same goes for the link to the source code provided in every example. But the Ajax Debug Window works quite nicely, as most of the Ajax examples. I'd anyone interested to try it out themselves, I definitely need feedback and review on all of this. To help out with testing, I'm going to provide a custom jetspeed-2.1.1-wicket-installer.jar with all wicket portlets already installed and accessible through the Jetspeed-2 page menus. That's going to be the next subtask/issue.

        People

        • Assignee:
          Ate Douma
          Reporter:
          Ate Douma
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development