-
Notifications
You must be signed in to change notification settings - Fork 3
Field architecture
The ecosystem of field types in Symphony 2 has grown messy, and it's worth discussing whether/how we can preempt some of those same issues when developing Symphony 3.
The following was proposed during a working group chat on 5 May 2011 (transcript).
Field architecture in Symphony 3 should be more or less what it was in Symphony 2.
The scope of this proposal is primarily around how fields are architected from a system perspective—i.e. what they're responsible for, what they consist of, and so on.
- ability to switch among fields with similar structures
- ability for fields to be extended without being duplicated
- custom/conditional validation
Despite the goals stated above, we were unable to come up with any acceptable improvements to the current field architecture. Adding additional layers for enhancements or further abstracting fields to allow for "swapping" both raised many more problems than they solved.