Coordination work

[julien1]

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.

[julien1]

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 ?

[julien1]

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

[bdaw]

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?

[bdaw]

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.

[julien1]

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:

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.

[julien1]

is it configurable from XML already ?

"bdaw" 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?

[bdaw]

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