David Sean Taylor wrote:
>>This is a has been around for a while, nothing new :(
>>
>
> Well maybe so, but its new to me, and its easily fixed with a simple check
> for null.
>
> Regardless checking for null obviously didn't fix the customizer, nor the
> root of the problem: why is there a portlet named 'PortletSetCustomizer'
> being passed to the PersistenceService (3 times for the Turbine psml) during
> customization, and why is it not found in the portlet set?
>
* The "_display" parameter is checked for max/min status of a portlet. So if
it's not found it's not a major issue but it may definitely be caught better.
* PortletSetCustomizer is the portlet that implements the current customizer
(yes, it's a portlet so it may swapped with a better implementation just
change the registry entry definition... :) )
* The invokation of the Customizer instead of the base PSML content is decided
by the "mode" of the currently invoked Turbine screen: if the mode is set to
"customize" the JetspeedTool loads the customizer instead of the selected
PSML content (cf JetspeedTool code)
--
Raphael Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Paris
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
