fuelphp-storage / email

FuelPHP Framework - Email library
1 stars 1 forks source link

Recipient management #3

Open sagikazarmark opened 10 years ago

sagikazarmark commented 10 years ago

Currently the Recipients are handled by ONE object. and can be identified by calling getType. Instead of this, one object/recipient type should be used (or at least considered), like this:

namespace Fuel\Email\Recipient;

class To extends Recipient { }
sagikazarmark commented 10 years ago

Should they be objects at all?

WanWizard commented 10 years ago

For me, don't create objects for the sake of it, a recipient is just a name and an email address. If they have to be objects, stdClass would do fine.

sagikazarmark commented 10 years ago

There are two main reasons I created an object:

I am still thinking about it: as you said, it is only an email address and a name.

WanWizard commented 10 years ago

The "string" form is a rendering of the email address, which technically depends on the selected transport. If you would use X.400 instead of SMTP, the address whould have a completely different form. So rendering should be done by the transport layer.

It is more important to make sure all info is present (in either an array, a stdClass or a custom object) to allow the transport layer to generate the correct address syntax. So you have fullname, address, recipient type, address type, and maybe other properties that are required or optional.

sagikazarmark commented 10 years ago

I am not sure if it is against a custom object solution or not. You are saying other properties, IMO it is easier to manage it with an object. The reason why I rarely use a stdClass is that it is hard to make sure it implements the required things (methods, properties).

I got it: should be generated by transport layer, I agree in that.

sagikazarmark commented 10 years ago

Changed it to return email when casted to string, any other generation/format process is moved to transport.

WanWizard commented 10 years ago

Thinking about this a bit more. If types are generic (i.e. an SMTP email address looks like "this", and an X.400 address looks like "that"), in other words, if these are standards, then you could encapsulate it in a custom object, or even have the object support both (which could be done through interfaces).

Then the class using recipients can just say: give me the address according to the X400 specs. Or the SMTP RFC. And the class should not need to know how to render, and what properties to use for that.

sagikazarmark commented 10 years ago

Sounds good.

The only reason against this solution is that there is an option for encoding headers, which again belongs to the transport layer. Encoding the whole formatted string is not an option, only the name, etc should be encoded, the email address not.