7 Replies Latest reply on Jul 23, 2008 5:04 AM by bdaw

    Coordination work

      I worked a bit on the coordination:

      I started to redo the samples to better reflect the various use cases, for now I have done explicit and implicit, fallback will be redone tomorrow probably

      I have an initial impl for linking page parameters to bindings of a page. It is possible to try the implicit and explicit samples.

      - in the explicit case, one need to use a binding name with values, like http://localhost:8080/portal/portal/default/Coordination+Samples/Parameters+EXPLICIT?binding1=daaa&binding2=blah

      - in the implicit case, it only works with the empty namepaced parameters that are declared by a portlet and urls use the parameter name, like http://localhost:8080/portal/portal/default/Coordination+Samples/Parameters+IMPLICIT?foo=blah

      The trick is that bindings are stored as empty namespaced parameters in the Map<QName, String[]> per page. So on an explicit page, the binding is stored as QName(XMLConstants.DEFAULT_NS_PREFIX, "binding1") and in the implicit case the binding is stored as QName(XMLConstants.DEFAULT_NS_PREFIX, "foo").

      The PortalObjectCommandFactory take any parameter in the page URL and will update the PageNS Map<QName, String[]> using the XMLConstants.DEFAULT_NS_PREFIX prefix when building the QName from the url parameters.


        • 1. Re: Coordination work

          one glitch I noticed is that in the explicit case, if a parameter is not explicit declared in a binding then it will simply never retain its state.

          It is visible in the explicit sample if you update PublicParametersPortletWindow1 juu1 parameter. The value is lost.

          I think it should rather remain private rather than being discarded, which would mean that in the explicit case this parameter is considered like a private parameters and is stored in the per window navigational state. Which would mean to add a Map<String, String[]> in the WindowNavigationalState to store such state.

          What do you think ?

          • 2. Re: Coordination work

            Is the alias implementation started (Map<QName, Set>) ? I haven't seen sample yet.

            • 3. Re: Coordination work
              bdaw

               

              "julien@jboss.com" wrote:
              Is the alias implementation started (Map<QName, Set<QName>>) ? I haven't seen sample yet.


              Yes. its in CoordinationConfigurator:

              /**
               * Set alias binding for a given page. If alias with given name already exists it will be overwritten
               *
               * @param page
               * @param aliasName
               * @param qnames
               * @throws IllegalCoordinationException
               */
               void setAliasBinding(Page page, String aliasName, Set<QName> qnames) throws IllegalCoordinationException;
              
               /**
               * Removes alias binding
               *
               * @param aliasInfo
               * @throws IllegalCoordinationException
               */
               void removeAliasBinding(AliasBindingInfo aliasInfo) throws IllegalCoordinationException;
              
               /**
               * @param page
               * @return collection of alias bindings connected to the given page
               */
               Collection<AliasBindingInfo> getAliasBindings(Page page);


              So at the moment the alias String name maps Set in scope of page. Should the alias name be QName rather?



              • 4. Re: Coordination work
                bdaw

                 

                "julien@jboss.com" wrote:
                one glitch I noticed is that in the explicit case, if a parameter is not explicit declared in a binding then it will simply never retain its state.

                It is visible in the explicit sample if you update PublicParametersPortletWindow1 juu1 parameter. The value is lost.

                I think it should rather remain private rather than being discarded, which would mean that in the explicit case this parameter is considered like a private parameters and is stored in the per window navigational state. Which would mean to add a Map<String, String[]> in the WindowNavigationalState to store such state.

                What do you think ?


                I remember we discussed it some time ago a bit. The thing is what behaviour would be expected. This would be the difference between FALLBACK and EXPLICIT strategy. In EXPLICIT param not wired is lost while in FALLBACK not.

                • 5. Re: Coordination work

                  it means that in the explicit case if you do not wire a public render parameter then it is never possible to set it with a value which means that the portlet will not work as expected.

                  "bdaw" wrote:
                  "julien@jboss.com" wrote:
                  one glitch I noticed is that in the explicit case, if a parameter is not explicit declared in a binding then it will simply never retain its state.

                  It is visible in the explicit sample if you update PublicParametersPortletWindow1 juu1 parameter. The value is lost.

                  I think it should rather remain private rather than being discarded, which would mean that in the explicit case this parameter is considered like a private parameters and is stored in the per window navigational state. Which would mean to add a Map<String, String[]> in the WindowNavigationalState to store such state.

                  What do you think ?


                  I remember we discussed it some time ago a bit. The thing is what behaviour would be expected. This would be the difference between FALLBACK and EXPLICIT strategy. In EXPLICIT param not wired is lost while in FALLBACK not.


                  • 6. Re: Coordination work

                    is it configurable from XML already ?

                    "bdaw" wrote:
                    "julien@jboss.com" wrote:
                    Is the alias implementation started (Map<QName, Set<QName>>) ? I haven't seen sample yet.


                    Yes. its in CoordinationConfigurator:

                    /**
                     * Set alias binding for a given page. If alias with given name already exists it will be overwritten
                     *
                     * @param page
                     * @param aliasName
                     * @param qnames
                     * @throws IllegalCoordinationException
                     */
                     void setAliasBinding(Page page, String aliasName, Set<QName> qnames) throws IllegalCoordinationException;
                    
                     /**
                     * Removes alias binding
                     *
                     * @param aliasInfo
                     * @throws IllegalCoordinationException
                     */
                     void removeAliasBinding(AliasBindingInfo aliasInfo) throws IllegalCoordinationException;
                    
                     /**
                     * @param page
                     * @return collection of alias bindings connected to the given page
                     */
                     Collection<AliasBindingInfo> getAliasBindings(Page page);


                    So at the moment the alias String name maps Set<QName> in scope of page. Should the alias name be QName rather?



                    • 7. Re: Coordination work
                      bdaw

                       

                      "julien@jboss.com" wrote:
                      is it configurable from XML already ?


                      Yes but I didn't test it :)

                      <!--
                      Shared render parameter bindings. Can be defined only for a page
                      -->
                      <!ELEMENT bindings (parameter-binding*, alias-binding*)>
                      
                      <!--
                      Alias binding definition
                      -->
                      <!ELEMENT alias-binding (name, qname+)>