Extra logic for a feedback form

Next topic

Author	Message
Ronan Limon Duparcmeur	Friday 02 April 2010 9:16:36 am After hitting my head against the wall and blowing off much steam on Twitter, I've finally been able to add some logic to what should have been a simple feedback form. For the record, here is my problem and how I solved it. One of our eZP-powered website features a simple feedback form. The catch ? Instead of sending an email, the submitted data has to be used to fill our CRM. This involves consuming a webservice, and thus some backend code. Since triggers aren't available on feedback forms (or, if they are, I just couldn't figure it out), we had to find another way. A custom module+action was out of question, so instead, we choose to add the extra logic in the feedback email template. So, basically, what we do is activate the sending of feedback emails (even though we don't want them), and in the overridden template for this email, we call a custom template operator. This operator, in turn, handles the call to the CRM's webservice. This is an ugly solution to a problem that shouldn't even exist in the first place. It may not be the best solution, but hey, at least the problem is solved for now.

Author

Message

Friday 02 April 2010 9:16:36 am

After hitting my head against the wall and blowing off much steam on Twitter, I've finally been able to add some logic to what should have been a simple feedback form. For the record, here is my problem and how I solved it.

One of our eZP-powered website features a simple feedback form. The catch ? Instead of sending an email, the submitted data has to be used to fill our CRM. This involves consuming a webservice, and thus some backend code.

Since triggers aren't available on feedback forms (or, if they are, I just couldn't figure it out), we had to find another way. A custom module+action was out of question, so instead, we choose to add the extra logic in the feedback email template.

So, basically, what we do is activate the sending of feedback emails (even though we don't want them), and in the overridden template for this email, we call a custom template operator. This operator, in turn, handles the call to the CRM's webservice.

This is an ugly solution to a problem that shouldn't even exist in the first place. It may not be the best solution, but hey, at least the problem is solved for now.