- This topic is empty.
September 16, 2014 at 3:35 pm #183311__Participant
if I had hard-coded HTML emails, I should store this among my model correct?
I’d put them in a config file (or something).September 16, 2014 at 3:43 pm #183312
You could separate further again with a database class.
I do have a parent class that has the core CRUD methods that each individual SQL method will call upon, so at least that’s not repeated.
I’d put them in a config file (or something).
I’m going to put the HTML itself into template files, but those will be called from some email views… now I just need to figure out how the hell to organize this… by email… page that called it… hmm…September 16, 2014 at 4:03 pm #183317
Now, I might be over-thinking this… but bear with me, this website has a lot of emails.
1) HTML for emails themselves will be in templates folder.
2) Location for templates will be in model (?)
3) Controller passes data to view which will assemble and send the email
Is #2 just taking things a step too far?
For #3, should the controller take care of the actual send part?September 17, 2014 at 3:53 pm #183430
To answer my own question based on what I’ve put together so far: I’m not doing anything in the model with emails, I’ll just have the view call any templates it needs to output the object.
I’m also just naming the templates after the email method name so there’s a direct correlation there.
So now my next quandry… if I’m just doing this:
$body = ob_get_clean();
I could technically just put the HTML in as a string in the view… am I gaining anything by keeping it in a separate file (other than reusability)?September 17, 2014 at 4:11 pm #183432__Participant
It’s usually easier to write the templates if they’re in a separate file. I have three approaches:
September 17, 2014 at 4:51 pm #183436
- separate html+php template, wrapped in an output buffer. This form is easy to write, especially since you don’t strictly need to know how it is included/parsed. I do this when clients or third parties might need to work with the template.
- separate php template (but no output, so no output buffer needed) which
returns a string when
included. I like this method best (it feels very “clean” to me), but it’s more fragile in case anyone else needs to handle them, so I don’t get to use this method as often as I’d like.
- string template written directly in the view class (or similar). I don’t really like this approach because I have to use string replacement (and/or wrap it in a function). I try not to do this except as a “fallback” template, or for really short strings.
OK – I think I’ll keep doing it inside the buffer, I’m going to be passing this project off to another team eventually. The easier things are to be reused, or edited, the better.
- The forum ‘Back End’ is closed to new topics and replies.