cancel
Showing results for 
Search instead for 
Did you mean: 

Support sending html emails with FreeMarker templates

tstephen
Champ on-the-rise
Champ on-the-rise
I imagine this would involve:

    Designer: adding an activiti:field name="htmlTemplate" in addition to the one named "html", probably a "textTemplate" in addition to "text".
    Designer: validating that either the existing field or the template one is populated
    Engine: modify the mail service task implementation to recognise these params and invoke the FreeMarker engine passing all the in scope variables to it sending the result to the SMTP server just as it does the html field today.
Personally I imagine that templates would be bundled with the process (bpmn) file and loaded from the classpath but I know of others who would wish to be able to deploy them independently.

Alternately, perhaps it is possible to use the existing templating (JUEL?) and simply hold it externally to the process file.
4 REPLIES 4

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
You can fairly easily make your own components for this… See extending the designer in the docs. That is what we did. If the basic mail service is extended, you have to also configure somewhere what templating is to be used etc… would make it more difficult then needed I think for the core engine…

tstephen
Champ on-the-rise
Champ on-the-rise
Thanks for your reply Ronald,

I've probably started from the wrong end, my real concern is that the core engine be able to send reasonably richly formatted mails and that there be a separation of concerns so that different people can author the process and the form / mail, which I hear from many customers. My comments about Designer were just for completeness assuming that the engine requirement would be uncontroversial.

Are you saying that you do not see a need for nicely formatted html emails? Or that the existing facility can provide this already? Maybe I have missed something… Obviously I could write my own email service task as well as some other work arounds but I felt this would be a useful feature to have in the engine. Apart from anything else it avoids me having to write it again for every customer!

Is there perhaps a concern that the engine would get bogged down in supporting many template languages? If so could we not figure out a similar approach to that used for forms on user tasks (http://activiti.org/userguide/index.html#externalFormRendering)?

cheers,
Tim

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
Reasonably formatted mails are possible imo wit the current engine. For Better formatted mails there are so many options, jsf, velocity, freemarker etc… Everybody has it's own preferences and maybe existing functionality, being able to also call things from outside the engine etc…

Compare this with all the discussions about the form in the forums. Functionality is never sufficient (that is why I never used the Activiti forms, not a complaint, just a fact)

I think Activiti should focus on being a great extendable, embeddable BPMN engine and have basic (but good enough) functionality for e.g. sending mail (as is currently supported, in basic html).

And why should you need to write it over and over again for each customer? If you have written one, you can re-use it can't you?

Maybe an 'extensions' repository wpuld be nice where people can publish their services (what about an xslt service?) so everybody could reuse it but it would not be part of the core…

tstephen
Champ on-the-rise
Champ on-the-rise
Ronald,

Again thanks, I get what you are saying about 'good enough' versus the effort of tackling a huge plethora of different templating technologies. And of course there will cases that I think I have a great generic solution but it turns out no one else wants it Smiley Happy

But the beauty of open source is that we get to road test that rather than have it centrally determined so perhaps you are right it is time for an extensions project. Where would you suggest, github? Perhaps the successful things get folded back into the core in the future.

And yes, XSLT service +1 from me.
Tim