Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.3
    • Fix Version/s: 2.2.0
    • Component/s: Customizer, PSML
    • Labels:
      None

      Description

      There is a wish for implementing "edit_defaults" custom portlet mode as descripted in JSR168 portlet specification:
      ----------------------------------------------------------
      PLT.A.3 Edit_defaults Portlet Mode

      The edit_defaults portlet mode signifies that the portlet should render a screen to set the default values for the modifiable preferences that are typically changed in the EDIT screen. Calling this mode requires that the user must have administrator rights. Therefore, only the portal can create links for changing the portlet mode into edit_defaults.

      Portlet developers should implement the edit_defaults portlet mode functionality by
      overriding the doDispatch method of the GenericPortlet class and checking for
      PortletMode("edit_defaults ").

      In the deployment descriptor the support for the edit_defaults portlet mode must be
      declared using
      <portlet-app>
      ...
      <portlet>
      ...
      <supports>
      ...
      <portlet-mode> edit_defaults </portlet-mode>
      </supports>
      ...
      </portlet>
      ...
      <custom-portlet-mode>
      <name> edit_defaults </name>
      </custom-portlet-mode>
      ...
      </portlet-app>
      -----------------------------------------------------------

      There is number of situations when there is need of different default preferences for same portlet type. There is a problem to change default preferences by administrator now. Because he must to edit psml files manually, without graphical interface.

      For example, i want my portal shows to all users rss feeds from bbc and cnn with RSS Portlets at main page of my portal. But administrators of my portal needs to know psml format to change read-only preferences, and they can't do it thru grafical interface.

      So, I think, many people wishes for edit_defaults portlet mode.

      So, this jira record is wish for edit_defaults portlet mode

        Issue Links

          Activity

          Hide
          Vitaly Baranovsky added a comment -

          David, you said about developing 'edit-defaults' custom portlet mode for the next release:
          http://www.nabble.com/Re%3A-release-preparation-and-JIRA%2C-next-release-version-p9066481.html

          So, can someone answer, when 'edit-defaults' will be developed?

          Show
          Vitaly Baranovsky added a comment - David, you said about developing 'edit-defaults' custom portlet mode for the next release: http://www.nabble.com/Re%3A-release-preparation-and-JIRA%2C-next-release-version-p9066481.html So, can someone answer, when 'edit-defaults' will be developed?
          Hide
          David Sean Taylor added a comment -

          Damn I let this one slip, simply forgot about it. The problem was it was not assigned to me.
          We are planning to release 2.1.1 Friday July 6, I can't see how I can get this coded up that soon, not with all the other features and bug fixes I have promised others.

          Show
          David Sean Taylor added a comment - Damn I let this one slip, simply forgot about it. The problem was it was not assigned to me. We are planning to release 2.1.1 Friday July 6, I can't see how I can get this coded up that soon, not with all the other features and bug fixes I have promised others.
          Hide
          Vitaly Baranovsky added a comment -

          > Damn I let this one slip, simply forgot about it. The problem was it was not assigned to me.
          David, this issue still unassigned...

          So, what is with this issue?

          Show
          Vitaly Baranovsky added a comment - > Damn I let this one slip, simply forgot about it. The problem was it was not assigned to me. David, this issue still unassigned... So, what is with this issue?
          Hide
          David Sean Taylor added a comment -

          I've assigned myself to this issue and will work on it for the 2.1.3 release
          It will also go in parallel to 2.2

          Show
          David Sean Taylor added a comment - I've assigned myself to this issue and will work on it for the 2.1.3 release It will also go in parallel to 2.2
          Hide
          Vitaly Baranovsky added a comment -

          David, I have some questions to you. Can you answer it?
          1) Where will be store portlet preferences after editing in edit_defaults portlet mode? In PREFS_NODE/PREFS_PROPERTY_VALUE tables? In .psml files? Or somewhere else?
          2) When do you plan to finish development with edit_defaults portlet mode? When do you plan 2.1.3 release?
          3) How can I convert my 2.0 preferences (stored in PREFS_NODE/PREFS_PROPERTY_VALUE tables with no_principal) to new persistence format?

          Great thanks!

          Show
          Vitaly Baranovsky added a comment - David, I have some questions to you. Can you answer it? 1) Where will be store portlet preferences after editing in edit_defaults portlet mode? In PREFS_NODE/PREFS_PROPERTY_VALUE tables? In .psml files? Or somewhere else? 2) When do you plan to finish development with edit_defaults portlet mode? When do you plan 2.1.3 release? 3) How can I convert my 2.0 preferences (stored in PREFS_NODE/PREFS_PROPERTY_VALUE tables with no_principal) to new persistence format? Great thanks!
          Hide
          David Sean Taylor added a comment -

          1) Where will be store portlet preferences after editing in edit_defaults portlet mode? In PREFS_NODE/PREFS_PROPERTY_VALUE tables? In .psml files? Or somewhere else?

          In PSML

          2) When do you plan to finish development with edit_defaults portlet mode? When do you plan 2.1.3 release?

          I am hoping to start on this task this week and finish within a week or so
          yes, it will be included in 2.1.3

          3) How can I convert my 2.0 preferences (stored in PREFS_NODE/PREFS_PROPERTY_VALUE tables with no_principal) to new persistence format?

          We will need a conversion utility for that

          Show
          David Sean Taylor added a comment - 1) Where will be store portlet preferences after editing in edit_defaults portlet mode? In PREFS_NODE/PREFS_PROPERTY_VALUE tables? In .psml files? Or somewhere else? In PSML 2) When do you plan to finish development with edit_defaults portlet mode? When do you plan 2.1.3 release? I am hoping to start on this task this week and finish within a week or so yes, it will be included in 2.1.3 3) How can I convert my 2.0 preferences (stored in PREFS_NODE/PREFS_PROPERTY_VALUE tables with no_principal) to new persistence format? We will need a conversion utility for that
          Hide
          Vitaly Baranovsky added a comment -

          > In PSML

          Great. I hope, it will dramatically increases starting up time of portal!

          > yes, it will be included in 2.1.3

          When do you plan 2.1.3 release?

          > We will need a conversion utility for that

          When do you plan to release such this utility?

          Show
          Vitaly Baranovsky added a comment - > In PSML Great. I hope, it will dramatically increases starting up time of portal! > yes, it will be included in 2.1.3 When do you plan 2.1.3 release? > We will need a conversion utility for that When do you plan to release such this utility?
          Hide
          David Sean Taylor added a comment -

          >> In PSML

          > Great. I hope, it will dramatically increases starting up time of portal!

          We are planning on writing a new implementation of prefs for 2.2
          It won't be included in 2.1.3

          >> yes, it will be included in 2.1.3

          > When do you plan 2.1.3 release?

          If all goes well within 2 - 2.5 weeks

          >> We will need a conversion utility for that

          > When do you plan to release such this utility?

          I will look into it with this issue

          Show
          David Sean Taylor added a comment - >> In PSML > Great. I hope, it will dramatically increases starting up time of portal! We are planning on writing a new implementation of prefs for 2.2 It won't be included in 2.1.3 >> yes, it will be included in 2.1.3 > When do you plan 2.1.3 release? If all goes well within 2 - 2.5 weeks >> We will need a conversion utility for that > When do you plan to release such this utility? I will look into it with this issue
          Hide
          Vitaly Baranovsky added a comment -

          >>>> 3) How can I convert my 2.0 preferences (stored in PREFS_NODE/PREFS_PROPERTY_VALUE tables with no_principal) to new persistence format?

          >>> We will need a conversion utility for that

          >> When do you plan to release such this utility?

          > I will look into it with this issue

          David, Woonsan, when do you plan to release conversion utility?

          Show
          Vitaly Baranovsky added a comment - >>>> 3) How can I convert my 2.0 preferences (stored in PREFS_NODE/PREFS_PROPERTY_VALUE tables with no_principal) to new persistence format? >>> We will need a conversion utility for that >> When do you plan to release such this utility? > I will look into it with this issue David, Woonsan, when do you plan to release conversion utility?
          Hide
          Vitaly Baranovsky added a comment -

          David, Woonsan, please, can you answer my question?
          Because of problem with storing preferences (https://issues.apache.org/jira/browse/JS2-782) I can't use Jetspeed Portal 2.1.2, and situation is very critical for me.
          Workaround is going away from edit mode of all my portlets to edit_defaults custom portlet mode, when preferences are storing in psml, not in database. But I have big portal with many portlets and many preferences (I've used old 2.0 behaviour of portlet preferences, when admin changes portlet preferences for guest users) . And very important for me to know when will be conversion utility. Can you answer?

          Show
          Vitaly Baranovsky added a comment - David, Woonsan, please, can you answer my question? Because of problem with storing preferences ( https://issues.apache.org/jira/browse/JS2-782 ) I can't use Jetspeed Portal 2.1.2, and situation is very critical for me. Workaround is going away from edit mode of all my portlets to edit_defaults custom portlet mode, when preferences are storing in psml, not in database. But I have big portal with many portlets and many preferences (I've used old 2.0 behaviour of portlet preferences, when admin changes portlet preferences for guest users) . And very important for me to know when will be conversion utility. Can you answer?
          Hide
          Woonsan Ko added a comment - - edited

          Vitaly, I can finish edit_defaults custom mode by this month. (So, it could be released in v2.1.3.) However, it seems like impossible for me to provide the conversion utility by this month because I'm going to have a big holiday week until next week. (It is Chuseok, a Korean thanksgiving feast. It is the biggest holiday in Korea. See http://en.wikipedia.org/wiki/Chuseok. )
          Also, I have to study the v2.0 behavior of portlet preferences. So, roughly speaking, I can start implementing the conversion utility at the second week of October if it is unavoidable. Thanks.
          By the way, if I implement and commit a skeletal skeletal tool, then I'll let you know for your testings.

          Show
          Woonsan Ko added a comment - - edited Vitaly, I can finish edit_defaults custom mode by this month. (So, it could be released in v2.1.3.) However, it seems like impossible for me to provide the conversion utility by this month because I'm going to have a big holiday week until next week. (It is Chuseok, a Korean thanksgiving feast. It is the biggest holiday in Korea. See http://en.wikipedia.org/wiki/Chuseok . ) Also, I have to study the v2.0 behavior of portlet preferences. So, roughly speaking, I can start implementing the conversion utility at the second week of October if it is unavoidable. Thanks. By the way, if I implement and commit a skeletal skeletal tool, then I'll let you know for your testings.
          Hide
          Vitaly Baranovsky added a comment -

          So, there today is last work day of the month. Have edit_defaults custom mode finished now?

          Show
          Vitaly Baranovsky added a comment - So, there today is last work day of the month. Have edit_defaults custom mode finished now?
          Hide
          Woonsan Ko added a comment -

          Hi Vitaly,

          The following basic functionality has been implemented and committed for edit_defaults custom mode:

          • A user who has a proper right can use edit_defaults custom mode.
            (Two options: only users in admin role or users granted by constraints/permissions. See theme-engine.xml.)
          • If the user changes the preferences, then the changes are stored in .psml via page manager.
          • Please note that a portlet should handle the edits_defaults mode properly. (See PickANumber portlet for example.)

          The commits will be reviewed by some developers next week before the 2.1.3 release. (Also, some advanced features can be considered.)
          Thanks.

          Show
          Woonsan Ko added a comment - Hi Vitaly, The following basic functionality has been implemented and committed for edit_defaults custom mode: A user who has a proper right can use edit_defaults custom mode. (Two options: only users in admin role or users granted by constraints/permissions. See theme-engine.xml.) If the user changes the preferences, then the changes are stored in .psml via page manager. Please note that a portlet should handle the edits_defaults mode properly. (See PickANumber portlet for example.) The commits will be reviewed by some developers next week before the 2.1.3 release. (Also, some advanced features can be considered.) Thanks.
          Hide
          Vitaly Baranovsky added a comment -

          Thanks, Woonsan.
          When does 2.1.3 release planned?

          Show
          Vitaly Baranovsky added a comment - Thanks, Woonsan. When does 2.1.3 release planned?
          Hide
          Woonsan Ko added a comment -

          Finished for edit_defaults custom mode.
          By the way, I will not try implementing the migration tool for some reason.
          So, I'd like to mark this issue 'resolved' now.
          Vitaly, if you still want a migration tool which might be contributed by someone, would you create another issue for the tool? Thanks.

          And, I wrote down some description below:

          1. Basic functionality

          Only users having admin rights (based on constraints/permissions) can use edit_defaults mode, and
          the default preferences are to be stored in PSML pages.
          To enable this feature, the portlet decoration properties should have
          'actions.factory=org.apache.jetspeed.decoration.CustomDecoratorActionsFactory'. See
          /decorations/portlet/tigris/decorator.properties.
          Implemented edit_defaults and about custom portlet modes for the PickANumber portlet.

          2. (Optional) Automatic dispatching option

          If a portlet does not support edit_defaults mode, but it supports edit mode, then Jetspeed can
          optionally provide automatic dispatching to doEdit() when the current portlet mode is edit_defaults.

          To enable this option:

          a) Set autoSwitchingToEditDefaultsModes to true for decorationValve in pipelines.xml like the
          following:

          <property name="autoSwitchingToEditDefaultsModes"><value>true</value></property>

          b) Set the first constructor arg to true for portletFactory bean in registry.xml like the
          following:

          <bean id="portletFactory" class="org.apache.jetspeed.factory.JetspeedPortletFactory">
          <!--
          If the following argument is true, then this factory will create proxy instances for
          actual portlet instances.
          Proxy instances will switch edit_defaults mode to edit mode automatically for portlets not
          supporting edit_defaults mode.
          -->
          <constructor-arg index="0">
          <value>false</value>
          </constructor-arg>
          </bean>

          c) Each portlet application should have custom portlet mode mapping declaration like the following (in portlet.xml):

          <custom-portlet-mode>
          <description>a Custom Edit_defaults Mode</description>
          <portlet-mode>edit_defaults</portlet-mode>
          </custom-portlet-mode>

          3. Limitations

          a) If the doEdit() method of a portlet is not public, then the system will not provide
          auto-dispatching for the portlet with no error.
          b) If a portlet provide edit_defaults mode, then the system will not provide auto-dispatching.
          Instead, it will hand over rendering to the portlet.
          c) If a portlet does not provide edit mode, then the system will not provide auto-dispatching.
          d) If a portlet application does not have custom mode mapping for edit_defaults, then the system will not provide auto-dispatching.

          Show
          Woonsan Ko added a comment - Finished for edit_defaults custom mode. By the way, I will not try implementing the migration tool for some reason. So, I'd like to mark this issue 'resolved' now. Vitaly, if you still want a migration tool which might be contributed by someone, would you create another issue for the tool? Thanks. And, I wrote down some description below: 1. Basic functionality Only users having admin rights (based on constraints/permissions) can use edit_defaults mode, and the default preferences are to be stored in PSML pages. To enable this feature, the portlet decoration properties should have 'actions.factory=org.apache.jetspeed.decoration.CustomDecoratorActionsFactory'. See /decorations/portlet/tigris/decorator.properties. Implemented edit_defaults and about custom portlet modes for the PickANumber portlet. 2. (Optional) Automatic dispatching option If a portlet does not support edit_defaults mode, but it supports edit mode, then Jetspeed can optionally provide automatic dispatching to doEdit() when the current portlet mode is edit_defaults. To enable this option: a) Set autoSwitchingToEditDefaultsModes to true for decorationValve in pipelines.xml like the following: <property name="autoSwitchingToEditDefaultsModes"><value>true</value></property> b) Set the first constructor arg to true for portletFactory bean in registry.xml like the following: <bean id="portletFactory" class="org.apache.jetspeed.factory.JetspeedPortletFactory"> <!-- If the following argument is true, then this factory will create proxy instances for actual portlet instances. Proxy instances will switch edit_defaults mode to edit mode automatically for portlets not supporting edit_defaults mode. --> <constructor-arg index="0"> <value>false</value> </constructor-arg> </bean> c) Each portlet application should have custom portlet mode mapping declaration like the following (in portlet.xml): <custom-portlet-mode> <description>a Custom Edit_defaults Mode</description> <portlet-mode>edit_defaults</portlet-mode> </custom-portlet-mode> 3. Limitations a) If the doEdit() method of a portlet is not public, then the system will not provide auto-dispatching for the portlet with no error. b) If a portlet provide edit_defaults mode, then the system will not provide auto-dispatching. Instead, it will hand over rendering to the portlet. c) If a portlet does not provide edit mode, then the system will not provide auto-dispatching. d) If a portlet application does not have custom mode mapping for edit_defaults, then the system will not provide auto-dispatching.
          Hide
          Vitaly Baranovsky added a comment -

          > By the way, I will not try implementing the migration tool for some reason.
          Woonsan, can you tell me reasons, why will you not try implementing the migration tool? Is there some big troubles to implement such a tool?

          Show
          Vitaly Baranovsky added a comment - > By the way, I will not try implementing the migration tool for some reason. Woonsan, can you tell me reasons, why will you not try implementing the migration tool? Is there some big troubles to implement such a tool?
          Hide
          Woonsan Ko added a comment - - edited

          As a result latest work, the guide I wrote before should be modified. The section 2 is simplified like the following:

          2. (Optional) Automatic dispatching option

          If a portlet does not support edit_defaults mode, but it supports edit mode, then Jetspeed can
          optionally provide automatic dispatching to doEdit() when the current portlet mode is edit_defaults.

          To enable this option:

          a) Set the following property to true in /WEB-INF/conf/jetspeed.properties.

          supported.portletmode.autoswitch.edit_defaults=true

          b) Each portlet application should have custom portlet mode mapping declaration like the following (in portlet.xml):

          <custom-portlet-mode>
          <description>a Custom Edit_defaults Mode</description>
          <portlet-mode>edit_defaults</portlet-mode>
          </custom-portlet-mode>

          Show
          Woonsan Ko added a comment - - edited As a result latest work, the guide I wrote before should be modified. The section 2 is simplified like the following: 2. (Optional) Automatic dispatching option If a portlet does not support edit_defaults mode, but it supports edit mode, then Jetspeed can optionally provide automatic dispatching to doEdit() when the current portlet mode is edit_defaults. To enable this option: a) Set the following property to true in /WEB-INF/conf/jetspeed.properties. supported.portletmode.autoswitch.edit_defaults=true b) Each portlet application should have custom portlet mode mapping declaration like the following (in portlet.xml): <custom-portlet-mode> <description>a Custom Edit_defaults Mode</description> <portlet-mode>edit_defaults</portlet-mode> </custom-portlet-mode>
          Hide
          Vitaly Baranovsky added a comment -

          Automatic dispatch option doesn't work! It should be corrected!

          I tried next activities to check whis option:
          I made
          supported.portletmode.autoswitch.edit_defaults=true
          in /WEB-INF/conf/jetspeed.properties

          In j2-admin.war project I have added line:
          <portlet-mode>edit_defaults</portlet-mode>
          into <supports> section of <portlet id="UserDetailsPortlet"> of portlet.xml.

          at the bottom of portlet.xml next lines exists:
          <custom-portlet-mode>
          <description>a Custom Edit_defaults Mode</description>
          <portlet-mode>edit_defaults</portlet-mode>
          </custom-portlet-mode>

          After this changes I've started jetspeed, I've logged in, but UserDetails portlet contains only edit mode icon (doesn't contains edit-defaults icon). When I made changes in this edit mode, preferences doesn't store to psml.

          Show
          Vitaly Baranovsky added a comment - Automatic dispatch option doesn't work! It should be corrected! I tried next activities to check whis option: I made supported.portletmode.autoswitch.edit_defaults=true in /WEB-INF/conf/jetspeed.properties In j2-admin.war project I have added line: <portlet-mode>edit_defaults</portlet-mode> into <supports> section of <portlet id="UserDetailsPortlet"> of portlet.xml. at the bottom of portlet.xml next lines exists: <custom-portlet-mode> <description>a Custom Edit_defaults Mode</description> <portlet-mode>edit_defaults</portlet-mode> </custom-portlet-mode> After this changes I've started jetspeed, I've logged in, but UserDetails portlet contains only edit mode icon (doesn't contains edit-defaults icon). When I made changes in this edit mode, preferences doesn't store to psml.
          Hide
          David Sean Taylor added a comment -

          Some things to check:

          1. make sure that you are not using a page with an old security ref definition. We updated the 2.1.3 security defs to include edit_defaults
          look in page.security for your constraint and make sure it has "edit,edit_defaults" both

          2. Make sure that your portlet decorator properties have this setting:
          actions.factory=org.apache.jetspeed.decoration.CustomDecoratorActionsFactory

          I don't think this is the case for the UserDetailsPortlet, but just for info...
          I have also seen one problem with calling doDispatch (not doEdit, doView or doHelp) in that the GenericPortlet in the portlet api doesn't consider custom modes
          In that case, in your portlet, try overriding:

          protected void doDispatch (RenderRequest request,
          RenderResponse response) throws PortletException,java.io.IOException
          {
          WindowState state = request.getWindowState();

          if ( ! state.equals(WindowState.MINIMIZED)) {
          PortletMode mode = request.getPortletMode();
          if (mode.equals(PortletMode.VIEW))

          { doView (request, response); }

          else if (mode.equals(PortletMode.EDIT) || mode.equals(JetspeedActions.EDIT_DEFAULTS_MODE))

          { doEdit (request, response); }

          else if (mode.equals(PortletMode.HELP))

          { doHelp (request, response); }

          else

          { throw new PortletException("unknown portlet mode: " + mode); }

          }

          although I think this should not be necessary in future releases as It should be handled in the portlet proxy

          Show
          David Sean Taylor added a comment - Some things to check: 1. make sure that you are not using a page with an old security ref definition. We updated the 2.1.3 security defs to include edit_defaults look in page.security for your constraint and make sure it has "edit,edit_defaults" both 2. Make sure that your portlet decorator properties have this setting: actions.factory=org.apache.jetspeed.decoration.CustomDecoratorActionsFactory I don't think this is the case for the UserDetailsPortlet, but just for info... I have also seen one problem with calling doDispatch (not doEdit, doView or doHelp) in that the GenericPortlet in the portlet api doesn't consider custom modes In that case, in your portlet, try overriding: protected void doDispatch (RenderRequest request, RenderResponse response) throws PortletException,java.io.IOException { WindowState state = request.getWindowState(); if ( ! state.equals(WindowState.MINIMIZED)) { PortletMode mode = request.getPortletMode(); if (mode.equals(PortletMode.VIEW)) { doView (request, response); } else if (mode.equals(PortletMode.EDIT) || mode.equals(JetspeedActions.EDIT_DEFAULTS_MODE)) { doEdit (request, response); } else if (mode.equals(PortletMode.HELP)) { doHelp (request, response); } else { throw new PortletException("unknown portlet mode: " + mode); } } although I think this should not be necessary in future releases as It should be handled in the portlet proxy
          Hide
          David Sean Taylor added a comment -

          one more thing to check, if you are using an old decorator, make sure it has the edit_defaults icon file

          Show
          David Sean Taylor added a comment - one more thing to check, if you are using an old decorator, make sure it has the edit_defaults icon file
          Hide
          Woonsan Ko added a comment -

          Hi Vitaly,

          IMO, I think you should remove the line you added in the <supports> section of <portlet id="UserDetailsPortlet"> of portlet.xml:

          <portlet-mode>edit_defaults</portlet-mode>

          The automatic dispatching option works only when the portlet does not support edit_defaults mode explicitly.
          By the way, the portlet should support EDIT mode, so the system can do auto-dispatching.

          To summarize:

          a) Set the following property to true in /WEB-INF/conf/jetspeed.properties.

          supported.portletmode.autoswitch.edit_defaults=true

          b) Each portlet application should have custom portlet mode mapping declaration like the following (in portlet.xml):

          <custom-portlet-mode>
          <description>a Custom Edit_defaults Mode</description>
          <portlet-mode>edit_defaults</portlet-mode>
          </custom-portlet-mode>

          c) Your portlet must support EDIT mode and it must have public doEdit() method.
          (For example, if your portlet extends GenericServletPortlet, then it already has public doEdit() method.)

          By the way, FYI, the PickANumber portlet is not an example for auto-dispatching option, but it is an example for manual implementation for edit_defaults mode.
          If you set configurations properly, the bookmark portlet in the default-page.psml will work as an example of auto-dispatching option when you log in by admin after installation.

          Regards,

          Woonsan

          Show
          Woonsan Ko added a comment - Hi Vitaly, IMO, I think you should remove the line you added in the <supports> section of <portlet id="UserDetailsPortlet"> of portlet.xml: <portlet-mode>edit_defaults</portlet-mode> The automatic dispatching option works only when the portlet does not support edit_defaults mode explicitly. By the way, the portlet should support EDIT mode, so the system can do auto-dispatching. To summarize: a) Set the following property to true in /WEB-INF/conf/jetspeed.properties. supported.portletmode.autoswitch.edit_defaults=true b) Each portlet application should have custom portlet mode mapping declaration like the following (in portlet.xml): <custom-portlet-mode> <description>a Custom Edit_defaults Mode</description> <portlet-mode>edit_defaults</portlet-mode> </custom-portlet-mode> c) Your portlet must support EDIT mode and it must have public doEdit() method. (For example, if your portlet extends GenericServletPortlet, then it already has public doEdit() method.) By the way, FYI, the PickANumber portlet is not an example for auto-dispatching option, but it is an example for manual implementation for edit_defaults mode. If you set configurations properly, the bookmark portlet in the default-page.psml will work as an example of auto-dispatching option when you log in by admin after installation. Regards, Woonsan
          Hide
          Woonsan Ko added a comment -

          I think it was already fixed before reopening. So, I'd like to close this issue.

          Show
          Woonsan Ko added a comment - I think it was already fixed before reopening. So, I'd like to close this issue.

            People

            • Assignee:
              Woonsan Ko
              Reporter:
              Vitaly Baranovsky
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development