In OOD, the Single Responsibility Principle generally advises that a class should only have one reason to change. The example you describe seems to clearly fall into a case where you probably don't want to mix form generation and processing.
However, in your example, you seem to have three distinct responsibilities:
- A structural representation of the form, complete with field definitions, etc
- A form-to-HTML process, that converts the form into an HTML representation.
- A Form-submission process, that evaluates the submitted data and produces a "filled out" form record (which may even be a fourth area of responsibility).
It's, of course, possible to mix together any number of these responsibilities together, however - I think you'll find that separating may create value, including:
- Decoupling of implementations
- Extensibility points for the future
- Separation of data representation from processing actions