EmailBuilder

[Graham Scott]

I've made an EmailBuilder service that uses nVelocity to create html
email messages. I think it's more flexible than rendering a view and
using that as the basis for emails, as is currently implemented.

Shall I pop it into a patch?

[Mike Hadlow]

Hi Graham,

Jeremy Skinner recently refactored the email rendering. Did you check the latest trunk? Have a look at that, if your implementation is still adding something, let's have the patch :)

Thanks
Mike

[Jeremy Skinner]

I haven't actually started on the changes to the email builder - I was going to do this as part of the changes for JtG. My approach was going to be very similar (except I was going to use Spark rather than NVelocity :)  I'd definitely like to see the patch.

Jeremy

2009/4/10 Mike Hadlow <mikeh...@googlemail.com>

[Graham Scott]

Hi guys

I've uploaded the patch to http://groups.google.com/group/sutekishop/files

2 caveats:

1. The proj file has a couple of references to my last patch in it,
which is not in the trunk so may cause an issue. How can I avoid these
clashes in future patches?
2. I've not created unit tests for this. I'm still pretty new to TDD,
and would love to create the tests, but I couldn't work out what
exactly should be under test. If anyone could give me some pointers
then i'll get it sorted.

Let me know what you think!

Graham

On Apr 10, 8:34 am, Jeremy Skinner <jer...@jeremyskinner.co.uk> wrote:
> I haven't actually started on the changes to the email builder - I was going
> to do this as part of the changes for JtG. My approach was going to be very
> similar (except I was going to use Spark rather than NVelocity :)  I'd
> definitely like to see the patch.
> Jeremy
>

> 2009/4/10 Mike Hadlow <mikehad...@googlemail.com>

[Jeremy Skinner]

Great, thanks. I'll try and take a look at this later today.

When working with patches, I tend to have one version of the source code checked out for each patch that I'm working on. This way, each patch can be developed in isolation and neither has a dependency on the other.

Regarding unit testing, I tend to start by writing a test that shows what the end result should be before I actually write any code. As an example, I might do something like this:

[Test]
public void Should_render_email() {
   var builder = new EmailBuilder("mytemplate");
   var result = builder.GetEmailContent();

   Assert.AreEqual("Some test content", result);
}

This then gives me the end result that I want to work towards and will then do the absoloute minimum to get this to pass. Once that's done, I can clean up the internals of the code while still ensuring that the test passes.

Jeremy

2009/4/10 Graham Scott <gho...@gmail.com>

[Jeremy Skinner]

I've applied the patch, but made a few changes.

- Changed the default path for the email templates to be Views\EmailTemplates rather than Content\EmailTemplates
- Tweaked method signature for GetEmailContent to take the template name and the viewdata rather than having them as ctor arguments. This way you can re-use the same EmailBuilder instance across the app.
- Removed the dependency on HttpContext.Current and instead made use of NVelocity's ResourceLoader support. This way the templates don't have to be actually part of the filesystem (eg, embedded resources)
- Added some tests (see EmailBuilderTester.cs)

I haven't yet changed any of the controllers to use the EmailBuilder - I'll get to that later today.

Let me know what you think.

Jeremy

2009/4/10 Graham Scott <gho...@gmail.com>