Pluto
  1. Pluto
  2. PLUTO-558

Change FilterManagerService to use portlet entity

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: portlet container
    • Labels:
      None

      Description

      the current FilterManagerService interface uses the
      PortletApplicationDefinition and the portlet name (string):

      getFilterManager(PortletApplicationDefinition portletAppDD, String
      portletName, String lifeCycle)

      I would like to change the signature of this method to use the
      PortletEntity:

      getFilterManager(PortletEntity, String lifeCycle).

      This would allow portals to provide different filter chains based on a
      portlet entity.

        Activity

        Hide
        Carsten Ziegeler added a comment -

        Changed to use PortletWindow in Revision: 771572

        Show
        Carsten Ziegeler added a comment - Changed to use PortletWindow in Revision: 771572
        Hide
        Carsten Ziegeler added a comment -

        I guess it somehow depends what the portal uses as the manageable unit: portlet entity or window. But I agree that we could use the PortletWindow for the signature as well.

        For your suggestion to drop PortletEntity:+1

        Show
        Carsten Ziegeler added a comment - I guess it somehow depends what the portal uses as the manageable unit: portlet entity or window. But I agree that we could use the PortletWindow for the signature as well. For your suggestion to drop PortletEntity:+1
        Hide
        Ate Douma added a comment -

        Carsten,

        While I've no objections to allowing more fine-grained configuration and handling of filtering, I'm not so sure the PortletEntity is the right level for this.
        Are you sure you want this to be differentiated only on the PreferencesSet used by the Portlet(Window)?
        I would suggest using PortletWindow instead of PortletEntity.
        Currently we have PortletWindow -> PortletEntity -> PortletDefinition -> portlet name, so using PortletWindow allows even finer grained configuration.

        Furthermore, I'm actually tempted to propose we drop PortletEntity as a qualified interface all together as Pluto (nor Jetspeed) doesn't use PortletEntity at all.
        For Jetspeed, I've already enhanced our (extended) PortletWindow to provide access to the PortletEntity (PreferencesSet) ID with method String getPortletEntityId() and also added getPortletDefinition() directly to PortletWindow.
        That greatly cleans up the code base as the PortletEntity 'intermediate' (now reduced to just an empty interface) then can be cut out from all the PortletWindow->PortletDefinition access usages.
        WDYT?

        Show
        Ate Douma added a comment - Carsten, While I've no objections to allowing more fine-grained configuration and handling of filtering, I'm not so sure the PortletEntity is the right level for this. Are you sure you want this to be differentiated only on the PreferencesSet used by the Portlet(Window)? I would suggest using PortletWindow instead of PortletEntity. Currently we have PortletWindow -> PortletEntity -> PortletDefinition -> portlet name, so using PortletWindow allows even finer grained configuration. Furthermore, I'm actually tempted to propose we drop PortletEntity as a qualified interface all together as Pluto (nor Jetspeed) doesn't use PortletEntity at all. For Jetspeed, I've already enhanced our (extended) PortletWindow to provide access to the PortletEntity (PreferencesSet) ID with method String getPortletEntityId() and also added getPortletDefinition() directly to PortletWindow. That greatly cleans up the code base as the PortletEntity 'intermediate' (now reduced to just an empty interface) then can be cut out from all the PortletWindow->PortletDefinition access usages. WDYT?

          People

          • Assignee:
            Carsten Ziegeler
            Reporter:
            Carsten Ziegeler
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development