Announcement Form

[Wmaxlees]

As a developer, I would like to know the form of the announcement objects

[robfitzgerald]

these are articles. i forget, @Wmaxlees , did we find out that we want to write announcements from orgsync, or that they provide an API to pass announcements from our site?

either way, how about something like this:

{
  createdDate: YY-MM-DD,
  modifiedDate: YY-MM-DD,
  author: "name",
  subject: "announcement title/subject of email",
  body: "the body of the annoucement, using some tagging system such as [#1-'caption'], [#2-'another caption'] to reference included photos",
  img: [
    {  1: image1.jpg },
    {  2: image2.jpg }
  ]
}

[Wmaxlees]

That looks good. I was thinking we should just pass everything on from our site to orgsync. Gives us more leeway on how we present our information

[robfitzgerald]

ok, they have a "show event" API. they don't have a "post event to orgsync" API, it seems. one-way. i didn't look too long, but, at least it's not posted as obviously as this was: https://orgsync.com/api/docs/v2/events/show

a typical return object:

{
    "category": {
        "id": 239192,
        "name": "General"
    },
    "description": "Our September outing will be to the Lakewood Chipotle! Make sure you fill out the survey of what you want before you attend so we can fax in our order and avoid the line!\r\n",
    "html_description": "<p>Our September outing will be to the Lakewood Chipotle! Make sure you fill out the survey of what you want before you attend so we can fax in our order and avoid the line!</p>\r\n",
    "id": 842234,
    "is_approved": true,
    "is_public": false,
    "location": "14881 Detroit Ave, Lakewood, OH 44107",
    "name": "Lakewood Chipotle",
    "occurrences": [
        {
            "ends_at": "2014-09-28T00:30:00Z",
            "is_all_day": false,
            "starts_at": "2014-09-27T23:00:00Z"
        }
    ],
    "org_id": 96921,
    "request_responses": [
        {
            "data": "It's not.",
            "element": {
                "id": 680892,
                "name": "How is this event open to the entire community?",
                "type": "TextArea"
            }
        },
        {
            "data": {
                "id": 1130911,
                "name": "No attendees will be charged."
            },
            "element": {
                "id": 680893,
                "name": "Will you charge attendees?",
                "type": "Radio"
            }
        },
        {
            "data": "Yes.",
            "element": {
                "id": 680895,
                "name": "What are the learning outcomes you have identified for participants?",
                "type": "TextArea"
            }
        }
    ],
    "rsvps": 1,
    "umbrella_category": null
}

[robfitzgerald]

so, our announcements page may not have a collection. it may simply be an http object that we unpack with angular. GET /api/v2/orgs/[ORG_ID]/events?key=[KEY]

[Wmaxlees]

Do we need to hang onto those keys? Or can we access a list of relevant keys from orgsync as well. We will still need to keep images on our side. So maybe just a database that links photos to their respective event key

[robfitzgerald]

this isn't regarding events, this is re: announcements. true, though, any pictures would be lost via this API.

[robfitzgerald]

hmm, keys. i think the smart way to do this is to have the angular site post to our webserver, which can store the key, and can perform the handling of the GET request to orgsync, and pass the result back to angular.

[Wmaxlees]

Ohhhh, I like that. That way, if we want to add more information, it's still a single call from the website to the node.js server and then the server can handle adding more info from the db.

[Wmaxlees]

We'll have to keep in mind that the object that the server receives will look different than the one that the website receives. That is if we clean out any unwanted info (like is_public) or add additional information (like picture links). We will have to note that in the wiki

[robfitzgerald]

is this going to far? let's skip tying in a local graphic for v1, eh? can can add that as an enhancement instead? but i think yea, we would just maybe inject an array in each request_response object containing image urls

[Wmaxlees]

Okay, I'll add images as an enhancement.

[robfitzgerald]

on angular -> node w/o using express: http://stackoverflow.com/questions/18327039/call-function-in-nodejs-from-angular-application otherwise, http://expressjs.com/starter/basic-routing.html

[Wmaxlees]

Oh I'm 100% for using express. It makes life so much easier

[robfitzgerald]

ok, whoops, i posted the schema above for orgsync API request for events. as far as i can see, they don't have one for announcements. ... we might just have to do something tricky. like, send announcements from orgsync to this site via email? no. hrm, you know, i'm kind of all-or-nothing about these options. either orgsync is our 100% option for posting new content, or, our own site is. so, one option we have is to use our github student pack, which includes sendgrid service for free. that's newsletter email management. we could use their API, and write announcements at our site from now on. maybe drop the orgsync event posts as well. this is a design question that i would want to share with jason too, at least.

[Wmaxlees]

Well if we're getting rid of orgsync all together, which I was sorta thinking about myself, we should do it all on our own. We can have a student sign up page. That doesn't add that much to what we've already created. We could use node and just use an gmail account. Check this out http://www.nodemailer.com/

At this point, really all OrgSync is giving us is a student list and event creation. But yeah, we should talk to Jason as well.

[robfitzgerald]

i feel like google would notice that and possibly mark it as spam if we use a basic gmail account. but, i'm down to give it a shot.

[Wmaxlees]

So before we started looking at OrgSync, I think this was your suggestion

{
   "createdDate": Date,
   "modifiedDate": Date,
   "author": "name",
   "subject": "announcement title/subject of email",
   "body": "the body of the annoucement, using some tagging system such as [#1-'caption'], [#2-'another caption'] to reference included photos",
   "imgs": [
       {
           "src": "image url" 
       }
   ]
}

I think this is good, except maybe we put the tagging system as an enhancement. Cause I can see that being a bit of a pain but also possibly being useful in other forms of posts besides articles/announcements. For example, "Contact [Rob] for further details" in an event post.

[robfitzgerald]

Sure that can be an enhancement but let's make it easy for our future selves by making sure 'src' is a unique integer in this version of the site. For now, the email will just attach the images iteratively, and 'src' can be ignored. We may need to learn about formatting the body. Whatever we end up using to handle emails will hopefully accept new lines, but, we might need to use some other delimiter to store newlines, tabs, etc in our database. Fun! On May 24, 2015 6:33 PM, "W. Max Lees" notifications@github.com wrote:

So before we started looking at OrgSync, I think this was your suggestion

{ "createdDate": Date, "modifiedDate": Date, "author": "name", "subject": "announcement title/subject of email", "body": "the body of the annoucement, using some tagging system such as [#1-'caption'], [#2-'another caption'] to reference included photos", "imgs": [ { "src": "image url" } ] }

I think this is good, except maybe we put the tagging system as an enhancement. Cause I can see that being a bit of a pain but also possibly being useful in other forms of posts besides articles/announcements. For example, "Contact [Rob] for further details" in an event post.

— Reply to this email directly or view it on GitHub https://github.com/amc-ucdenver/website/issues/3#issuecomment-105081588.

[Wmaxlees]

This is the announcements that are appearing on the main page. The email portion of announcements and articles goes here: #63. Otherwise, yeah I think it's a good idea to have unique id's for images. Id's in Mongo are by default actually strings of integers and chars (ie 9k2k9s21919jld7434ks). We could use something like:

art005-001 where the first part tells us it's an image for an article and specifically article number 5. The second part tells us it's the first image for that article.

I'm not sure what you mean by the program going through the images iteratively. You mean we tell the program the first and last image or the first image and the number of images and then it just counts up?

[robfitzgerald]

sorry i was being vague there, re: iteration. in terms of popping the announcement up from JSON form up to a concrete web element form, i'm thinking an integer for 'src' is the bare minimum and simplest way to let the angular directive know how what image goes where on the page. we could enforce a rule such that, for each appearance of some agreed upon identifier (for example, '[#-'caption']' where # is an integer), that identifier is replaced by the image. this is the convention that many CMSs use.

taking our example:

{
   "createdDate": Date,
   "modifiedDate": Date,
   "author": "name",
   "subject": "announcement title/subject of email",
   "body": "the body of the annoucement, using some tagging system such as [1-'caption'], places the image with index 1 inline with this text, with the caption 'caption'",
   "imgs": [
       {
           "1": "image.jpg" 
       }
   ]
}

[robfitzgerald]

the email discussion goes in #63. but, just confirming, an email and its associated announcement content only exist in one place on the site, which is in the announcement JSON object, right?

assuming this is the case, we are in a position where we should only have to write an announcement once, and it should work for both emails and announcement views. so, let's pick the one that has greater requirements (likely the email process) and therefore write these objects to fit those rules.

• so, choosing our email service, leads to copying their object format and inline email symbology, which leads back to forming our event object.

we can strip out whatever formatting symbology our email handler requires when we load an announcement view on our site.

SO! let's try out the node service you found, and i also want to give the sendgrid API a shot since we get that for free with our github student pack. what do you think?

[Wmaxlees]

Ooohhh. That's slick. Maybe we should use array indices instead of actually having the number in the JSON object, though. I think it would be really difficult to save something like

{
   "imgs": [
        {
            "1": "image1.jpg",
            "2": "image2.jpg",
            ...
        }
   ]

in MongoDB using mongoose (the MongoDB library for node.js). We would have to create a schema that has all the numbers already in it. We can't have it auto-generate the number for us I don't think.

Re: the email discussion, that's a good point. Let's take a look at what sendgrid and nodemailer require. If it's something that we can't easily implement on top of our current format, we should definitely plan ahead for it. But if we can make the change fairly painlessly down the road at some point, we shouldn't worry about it now. I think this comes back to the Agile vs. Waterfall mentality again.

[robfitzgerald]

i guess i don't know about that. does mongoose require keys to be the same for each document in the key value pairings in JSON? if so, yea, the quickest fix is to make it an array, which we can iterate through. we would have to have something on the angular side inform the user what the numbering system is. i'm going to add some links to #63 about sendgrid options and then go walk my dog. :dog2: