SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

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

    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:

    PHP Code:
    [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

  2. #2
    <?php while(!sleep()){code();} G.Schuster's Avatar
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #3
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by G.Schuster View Post
    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?

    Quote Originally Posted by G.Schuster View Post
    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?

    Quote Originally Posted by G.Schuster View Post
    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?

    Quote Originally Posted by G.Schuster View Post
    BTW, development shouldn't extend production - it shpuld be the other way round, as in the development process.
    Are you talking about this?
    PHP Code:
    [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:
    PHP Code:
    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

  4. #4
    <?php while(!sleep()){code();} G.Schuster's Avatar
    Join Date
    Mar 2007
    Location
    Germany
    Posts
    428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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

  5. #5
    SitePoint Wizard
    Join Date
    Feb 2009
    Posts
    1,006
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by G.Schuster View Post
    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.

    Quote Originally Posted by G.Schuster View Post
    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

  6. #6
    SitePoint Addict SirAdrian's Avatar
    Join Date
    Jul 2005
    Location
    Kelowna, BC
    Posts
    289
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I always prefer to do it at a more global level, via alternate mail transport.
    Testing Zend_Mail « Adrian Schneider
    Adrian Schneider - Web Developer


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •