Zend Framework - Multi Stage scenario (production and developer emails)

[oikram]

Hello all,

On our development servers, when we work with forms and we test them, normally we use our own emails so that, when we test, we can receive those results and see if it's all working.

When we change to production, we must change those emails to "production" emails.

Often, we tend to forget that, and not so uncommonly we are receiving data that we shouldn't and, at the same time, our production beneficiaries aren't receiving what they should.

How/where can we define our emails so that, when we are on the developing side, we have our dev email called and, when we are on production side we have our production emails called?

Please note:
I'm not that concerned with status messages, or emails that we use while stress testing something odd, no bug notifications, nothing like that.

I'm talking only about those emails that normally, we use to send form informations into.



I believe that application.ini is the right place to deal with this. Perhaps:

[production]
contact.email.address = "trueemail@email.com"
contact.email.name = "John Stuart"

joinus.email.address = "anotheremail@email.com"
joinus.email.name = "Patricia Bill"


[development : production]
contact.email.address = "my@email.com"
contact.email.name = "Devname"

joinus.email.address = "my@email.com"
joinus.email.name = "Devname" 

But if we do such a thing I quickly have a problem and a question:

Problem:
If we have 10 forms on the application, I defeat the dry principle on the [development] environment, since I have to write 10 times the same address and name.

Question:
If this approach is still acceptable, and by knowing that I will probably use Zend_Form, how should I call those values when I have to program the form?



If this approach is NOT acceptable, what do you suggest ?
Thanks a lot,
Márcio

[G.Schuster]

I'd follow a simple principle: define a standard and only specify special cases when really needed.
E.g. "standard.email.address" that all forms could fall back to if there's no "specialform.email.address" defined.
When in development, only specify "standard.email.address" and you're done.

As on how to implement - I'd create an application resource, that handle's the address selection, e.g. "$resource->getAddressForForm('formName').
It lokks at the current config if there's a formName.email.address and returns that or the standard.
Simple thing, no overhead, target hit.

BTW, development shouldn't extend production - it shpuld be the other way round, as in the development process.

[oikram]

I'd follow a simple principle: define a standard and only specify special cases when really needed.
E.g. "standard.email.address" that all forms could fall back to if there's no "specialform.email.address" defined.
When in development, only specify "standard.email.address" and you're done.

Nice. And when we would have the need for more emails then just the standard one, what should we do?

As on how to implement - I'd create an application resource, that handle's the address selection,
e.g. "$resource->getAddressForForm('formName').

I more or less got your example, what is an application resource?

It lokks at the current config if there's a formName.email.address and returns that or the standard.

I still need to grasp the application resource meaning, however, I'm not yet getting, if I need to inspect config (and if that is this "application.ini") how can we inspect there?

BTW, development shouldn't extend production - it shpuld be the other way round, as in the development process.

Are you talking about this?

[development : production] 

Zend tool himself has created this order.
This indicates that the development stage will inherit
any configuration variables( they are not variables... hm... things ) defined within the production stage.

Like:

includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
appnamespace = "Application"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers" 

Should I place those on:
[development] and then create a [development : production] ?

We must consider that Zend Tool defaults behaviour should not be taken as a no sense choice, so a reason must exist for it, to do this differently, what could that reason be?



Thanks a lot for your reply,
Márcio

[G.Schuster]

Regarding Application resources:
- Take a look at Zend/Application/Resource/*
- Read the docs: Zend Framework: Documentation: Available Resource Plugins - Zend Framework Manual

Long story cut short: if you have a "resources.db.xyz"-config in your application.ini this is already handled for you by the "db" application resource shipped with ZF.
You may extend that by creating your own resources, e.g. "resources.mailing.xyz" would be handled by "Yourlib_Application_Resource_Mailing".



Regarding configuration extension:
Well...what comes first?
Development or production?
It's kind of personal preference - I choose to let testing extend development, qa extend testing, staging extend qa and production extend staging.
For me, it follows the process route an application in general goes.
On the other hand, when development extends production, you minimize the risk of having e.g. exception throwing not turned off in the production environment when it was turned on for development.
As far as I can remember, the docs stated the route I use when I read them the last time - more than a year ago

[oikram]

Regarding Application resources:
- Take a look at Zend/Application/Resource/*
- Read the docs: Zend Framework: Documentation: Available Resource Plugins - Zend Framework Manual

Long story cut short: if you have a "resources.db.xyz"-config in your application.ini this is already handled for you by the "db" application resource shipped with ZF.
You may extend that by creating your own resources, e.g. "resources.mailing.xyz" would be handled by "Yourlib_Application_Resource_Mailing".

That seems powerfull. I will have the proper readings there. Thanks.

Regarding configuration extension:
Well...what comes first?
Development or production?
It's kind of personal preference - I choose to let testing extend development, qa extend testing, staging extend qa and production extend staging.
For me, it follows the process route an application in general goes.
On the other hand, when development extends production, you minimize the risk of having e.g. exception throwing not turned off in the production environment when it was turned on for development.
As far as I can remember, the docs stated the route I use when I read them the last time - more than a year ago

I don't mind to not follow some rules if, of course, I perfectly understand the reasons for doing so. That will help me out to decide.

Again, thanks for your time.
Márcio

[SirAdrian]

I always prefer to do it at a more global level, via alternate mail transport.
Testing Zend_Mail « Adrian Schneider