7 Replies Latest reply: Jul 23, 2008 5:04 AM by Boleslaw Dawidowicz RSS

Coordination work

Viet Master

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
    Viet Master

    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
    Viet Master

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

  • 3. Re: Coordination work
    Boleslaw Dawidowicz Master

     

    "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
    Boleslaw Dawidowicz Master

     

    "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
    Viet Master

    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
    Viet Master

    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
    Boleslaw Dawidowicz Master

     

    "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+)>