While implementing the Portlet Hub prototype, I discovered that the Pluto implementation did not take the Qname into account when mapping public render parameters. I believe this to be an error. The Portlet Hub has to handle public render parameters, so a different type of mapping would be relevant for the Portlet Hub prototype.
To make sure that the Portlet Hub implementation would work wwith a Qname-based mapping, I fixed the problem. It turned out to be a bigger exercise that I had anticipated. In preparation for implementing a prototype for the V3 server-side parameter handling changes, I also changed the URL encoding to remove redundant portlet ID information. The fix entailed: * Added a public render parameter mapping service that maps the public render parameters into groups. The mapping service can be implemented to map public render parameters based on any available criteria. * Implemented a public render parameter mapper that forms groups on the basis of QNames * Propagated the configuration & PRP value info to the URL generation code * Introduced something similar to Huffman encoding for the portlet window IDs contained in the URL, so that each ID appears only once * Added PRP group information to the URL * Adapted the Portlet Hub implementation to the new URL format * Adapted the Portlet Hub implementation to handle the PRP group information The fix is contained in the Portlet Hub branch for your viewing pleasure ... Mit freundlichen Grüßen, / Kind regards, Scott Nicklous WebSphere Portal Standardization Lead & Technology Consultant Specification Lead, JSR 362 Portlet Specification 3.0 IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martina Koederitz / Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
