Florent Guillaume <[EMAIL PROTECTED]> writes:

> 
> A heads up for widget developers:
> 
> The Widget Types Tool has been removed. Widget code and registration  
> now gets simpler. The Compound Widget now also takes the role of the  
> previous Customizable Widget.
> Previous standard Compound or Customizable widget types (Link Widget,  
> Text Image Widget, Image Link Widget, Search Widget, Search Location  
> Widget) are now defined in code and not in widget type configuration.
> 
> Have a look at ExtendedWidgets.py for instance if you want to see  
> what's changed:
> - the widget's meta_type is the "key" used by layouts definitions to  
> choose the widget type (so the "CPS" prefix has been dropped),
> - the registration is now done using widgetRegistry.register(XYZWidget),
> - there is no "widget type" class registration anymore,
> - if you want to define a compound widget in code, look at examples  
> like CPSLinkWidget, they use the CPSProgrammerCompoundWidget base class.
> 
> Florent
> 

Hello,

Some weeks ago, I created a "special" compound widget with a layout defined in
the ZMI. This widget extends CPSCompoundWidget.
I faced a problem in FlexibleTypeInformation.flexibleDelWidgets (CPS3.3.3 and
CPS3.3.7): this method uses the meta_type to see if it's a compound widget
whereas FlexibleTypeInformation.flexibleAddWidget test if the widget is a
subclass of CPSCompoundWidget.
The only fix I found was to use the same meta_type as the CPSCompoundWidget
(sorry, no time to crate a ticket...).
I understand the new way for creating a compoud widget (subclass
CPSProgrammerCompoundWidget). But it seems that
FlexibleTypeInformation.flexibleDelWidgets did not change in CPS 3.3.8 (test of
the meta_type).

My question is: will it work if my widget subclasses CPSProgrammerCompoundWidget
  with it's own meta_type?

Ouups, I forgot: Thanks for CPS, it's really a great product!



_______________________________________________
cps-devel mailing list
http://lists.nuxeo.com/mailman/listinfo/cps-devel

Reply via email to