If you want to accomplish that by yourself, you would need to study eZ a bit one way, or the other.
The default way is to create a class that would collect information (info collector flag of a class attribute). More info:
http://ez.no/doc/ez_publish/technical_manual/3_10/concepts_and_basics/content_management/information_collection You don't worry that much about validation in such case, it's taken care of if you use built-in attribute data types.
Alternatively, you may prepare your own extension with a module/view for displaying/receiving data and deal with everything on your own. That requires more knowledge and also PHP programming.
I know how to setup a class for doing form collection and setting up a template to show the form (based on the admin edit page from ez).
I've 3 problems to solve:
1. How to override the way input errors are shown?
2. The edit page has a logic of creating drafts and a cancel button when you quit... how can I bypass this to have a real form (one click submit, go away to dismiss)? 3. How to send the e-mail in the end?
We might have taken the wrong approach to begin with...
1. What exactly do you want to change about validation messages?
2. This one actually I don't know out of the box, but I'm sure enough it would be possible if you study the templates. Out of curiosity, what is wrong about that confirmation behavior? 3. Where should the e-mail go? Look at the settings/collect.ini file configuration options.
1. The validations I want are a little bit complex (field depending on other fields and such);
2. The fact that most of the users will simply take the trouble the click on the cancel button and my experience shows me that after a while things start going wrong when the draft are not properly cancelled (maybe there is a way to do this automagically)? 3. The e-mail can be defined in the settings file but it has to follow a specific template
Right now I've the forms implemented with the validations and sending the e-mail as required. But to fulfill the requirement the info should also be saved in the database. Another way to do it if somebody knows how would be to call PHP code to save the data in the database?
The first point is already, in my opinion, reason good enough to move towards own dedicated form extension. It might be possible to override default template behavior for collecting info of particular class, but the truth is any serious logical operations, decisions, validation should be performed in PHP rather than in the presentation layer (templates). And information collection mechanism is very handy, but quite simple as the matter of fact.
In such case, I'd create an extension with custom module views that handle form displaying and validation, and a custom persistent dataset (database table) for storing any results. All of your problems will have straightforward solutions then, as long as you can handle them properly in PHP and as a extenson.
Dig the net and ez.no if you need more info on info on the above. Good luck!