(3a & 3b) SparkPost transaction that acctually dispatches a mailing


This is mockup of the (3)st #SparkPost transaction in Newsletter Mailing System

POST –  https://api.sparkpost.com/api/v1/transmissions?num_rcpt_errors=3
{
    "options": {
        "open_tracking": true,
        "click_tracking": false },
  "campaign_id": "mailing DATE-ENTRY”,
  "return_path": "customer.service@speaktomecatalog.com",
   “recipients": { “list_id” : “WHATEVER-LIST” }
   “content”: { “template_id” : “WHATEVER-MAIL-PIECE” }
}
 

Normally the only input to the TD button would be DATE-ENTRY.   For tracking purposes the campaign id should be unique for each mailing.   The WHATEVER-LIST will almost always be “newsletter” or “test”.   The WHATVER-MAIL-PIECE” will almost alwys be “current”.   But #shucks would nice to be able to build whatever buttons i need null

i am not sure the significance of the  num_rcpt_errors=3 parameter.

Comments


nathan i just dawned on me that we don’t have the “campaign_id” programmed correctly. 
that should be clear from looking at the actual mailing logs … i downloade them from sparkpost and uploaded them here

each mailing must have a unique campaign id.  otherwise there is no way to get a report of the results.

so as not to require a new input from the operator i suggest the following …

the object of  "campaign_id" should be the contatination of: 
the subject of the emailing + the date of mailing + “test” | “live”

Okay

Partially done. The campaign_id now contains current date and “(test)” or “(live)”.

The subject is not known at the time the email submit button is pressed because html forms are stateless and there is no persistent storage available. The correct way to solve this in the web dynamics model is not to use a persistent value anyway, but to read the “current” template from sparkpost and get the subject from it. That is the only way to guarantee the correct value in all possible ways to click the buttons. I have a button for that, but to do it in the context of the email campaign button would require an asynchronous wrapper for that function. If having the subject in the campaign_id is critical to function, then I will write such a wrapper when I get a null.

Also, you will have to copy the script from (master) to your children taking care to replace the 3 JSON variable blocks at the top with your own new ones (and only those 3 because the whole rest of the script has already evolved, including stuff above those 3).

okay great … #thanks → nathan … it will actually work quite well without the subject in the campaign id. 

Of course here in a thinking.live domain, unlike at Postman, we do have access to the persistent storage of the quads table.  All that would be required, me thinks, would be to grant read/write access from your button language … scoped to the  protected context of the thought itself, of course.

#shucks how much would that cost and/or woud you be interested?

tag #quads


In general, It is something I want to add, yes. But it needs careful thought in order to be a truly useful and stable and easy to use feature. It is not something I want to just hack together.

And even if we had that, it should not be used in this situation. It breaks web dynamic rules because.
  1. It makes the clicking of the buttons hyper dependent on the user following an exact procedure. As you well know, humans often don’t do that. If a human clicked the buttons in a different order the value would be wrong.
  2. Loss of internet during part of the procedure (even unknown to the human) could cause wrong values.
  3. It doesn’t matter if the trip is to the Thinking Domain or to Sparkpost, it is still an ajax trip to get the value. Better to get the real value that is going to be used by the rest of the current procedure from the actual sparkpost template than a saved value from the quads which may or may not be the actual desired value. That is correct web dynamic programming and that’s the only kind I write.  
You see, all the components inside a single button click are atomic and if the internet fails in that context the whole button procedure aborts with an error. However, clicks between different buttons are not atomic and if the internet fails in that stateless zone (and you don’t notice) then the value could be wrong. We (web developers) are always supposed to write individual button clicks to be completely self contained and not rely on information from any other button click if at all possible, and in this case it is entirely possible.

Well it would certainly change how the procedure would be written … but when written that way none of your 3 points would happen.   In fact it would be quite slick indeed .. and would totally eliminate the need to ever edit the script.  If you want i will mock up the procedure done with permant memory of state … #omg it would be sooo slick null

… but hey, this is way beyond what i need to move on to another project.

tag #quads

No, I don’t want to mock it up that way. It would be a hack. There is no way around those 3 above. This is something I learned (and later wrote my own paper on for Virtual Sellers) way back in the 90’s when I first started programming in a stateless environment. You never have seemed to grok the nature of web dynamics. You program for the web as if it is Foxpro or Visual Basic. And although you can often hack things to sort of work that way when nothing goes wrong, it is not a foolproof way to program for the web. I don’t write web hacks anymore. They are never worth it and almost always there is a real way to do it in the web dynamic way that is no more work … which is exactly the case here.

… as I said. If you need the subject in the campaign_id then I will write the right code to do that for you that gets the real value from the real template. It would take me about 15 minutes. I won’t write a hack.

… and p.s. one of the reasons TD software is so incredibly stable overall is because I have a “no hack” policy. (the few remaining oddities notwithstanding, they have more to do with your crusades than anything else).

I am off to an end of season school play. Back later.

my mock up woud not be a hack.  and yes there is a way around all 3 of your fears.

hint:  the thought itself is put in a state deterimined by it’s quads. 

for example here are some quads that would make it work …
 
context subject verb object notes
URL OF THOUGHT campaign-id subject subject from <title> written when “update current template was pressed”  campaign id calculated as per my origninal request
URL OF THOUGHT campaign-id “from date” CURRENT DATE written when “update current template was pressed”
URL OF THOUGHT campaign-id “to date” CURRENT DATE written and used when “retrieve bounces” buttn is set … and cleared when a new template button is clicked.

the kewl thing here null is that i would not need to guess it at all .. or edit a script.
         

bear in mind that this is rough draft of thinking out loud here … i would need to think some more about it.   The subject and dates and campagns could always be shown explicitidly in the procedure ...telling the operator the status of the the thought procdeure.   If buttons were pressed out of sequence no harm could be done and variables couuld be blanked or displayed logically.

… not necessary as i said above.