Ticket #2396 (new enhancement)

Opened 8 years ago

Last modified 7 years ago

Improve transparency of Indirect Widget

Reported by: gracinet Owned by: gracinet
Priority: P2 Milestone: CPS 3.6.1
Component: CPSSchemas Version: 3.5.2
Severity: normal Keywords: indirect widget properties


Indirect Widgets are now the foundation of the flexible layouts system. Additional properties on Indirect Widgets can act as overrides of the templates they refer to.

New usages, such as those of CPSUserForms demonstrate that changing the properties of an Indirect Widget is a bit problematic. In most cases, what the calling code really wants is changing properties which may have not yet been overridden at the Indirect Widget level.

Therefore, instead of polluting the calling code (CPSUserForms, e.g), we should change manage_changeProperties for Indirect Widget instances so that it would transparently add a new property on the Indirect Widget itself if needed. This is quite simple, can be unit-tested and documented independently and has no impact on the ZMI screen (they would call manage_changeProperties for the properties defined on the Indirect Widget itself only anyway).

In the example of CPSUserForms, this would help keeping the difference between the 3.4 and 3.5 branches (currently default/trunk) to a minimum

Change History

comment:1 Changed 8 years ago by gracinet

  • Milestone changed from CPS 3.5.3 to CPS 3.5.4

After a bit of investigation, this is some kind of Pandora box. Indeed, we use in the Indirect Widget two levels of properties (the template widget's, and the indirect's) but they are somehow separate enough. Trying to do as suggested above starts interlacing them, and can actually be done without stoping relying on properties to store the overrides of the Indirect Widget, which means upgrade step etc.

This is not worth the effort for now -> rescheduling to 3.5.4, which for now means "later"

comment:2 Changed 7 years ago by gracinet

  • Milestone changed from CPS 3.5.5 to CPS 3.6.1

This is dangerous ground, we can live without it in 3.5 branch, which is now supposed to be stable. Perhaps Zope > 2.10 will provide a better way to handle this

Note: See TracTickets for help on using tickets.