Hi,
I'd like to organize the package layout of CForm classes in order to cleanly separate API classes from implementations classes.
By API classes, I mean not only interfaces, but also helper abstract classes. These interfaces and classes are those that we'll have to maintain and keep backwards compatible once we put the "stable" stamp on the forms block, whereas implementation classes will have to be kept compatible from a user point of view (naming and behaviour), but can be refactored in their implementation.
For this, I'd like to move implementation classes into an "impl" subpackage in the respective API packages.
I also would like to flatten the CForms component hierarchy, i.e. avoid the creation of a ComponentSelector in the FormManager and BindingManager. The purpose is to facilitate the use of another container and the definition of new widgets/datatypes/validation rules in blocks/subsitemaps.
A nesting is currently required for convertors, since they are attached to a particular datatype. To remove this need, we may use a naming convention, prefixing the convertor and format name by the corresponding datatype component name, i.e. "long-formatting", "date-formatting", etc.
Thoughts?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
