Skip to content

Instantly share code, notes, and snippets.

@armincifuentes
Last active May 29, 2017 18:44
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save armincifuentes/70ef1ea9fe5e07c081edf6d0a166fc0a to your computer and use it in GitHub Desktop.

Tweets Content Type

Database

Initially I'd go with ContentRequest -> ContentTweets -> ContentNode -> ContentNodeRevision:


                                     ContentNode     ContentNodeRevision
                                   /               /
ContentRequest --> ContentTweets --- ContentNode --- ContentNodeRevision
                                   \               \
                                     ContentNode     ContentNodeRevision
                                          \
                                           \-- ContentNodeRevision
                                            \
                                             \-- ContentNodeRevision

We could eventually skip one level, but would require a self-reference in the revisions table with something like child_revision_id or parent_revision_id and will be trickier to pick the current / latests revisions. Harder to maintain and keep up with.

Models

ContentTweets

As with any ContentType model, this will hold the specific guidlines for the request:

Field Description
Handle Twitter profile where tweets will be published. If available, will be retrieved from Project Profile, so should be in URL format.
Hashtags Keywords equivalent. Also stored as JSON Array or simple comma delimited strings. Since it's a bunch of tweets, there's no point in limiting amount.
Type Array with one or more from: link, question, quote, tip
Media Array with one or more from: none, pictures, GIFs, Videos
Goals Array with one or more from: retweets, favs, replies

ContentNode

It'll be a mutable node which works as an aggregator for copy and media. To be used later on with listicles, FB Posts and maybe even infographics so the user can approve or reject each node on its own. Anything measured by count rather than length.

ContentNodeRevision

Would be attached to a ContentNode in a 1-n relationship. If reduced down to just a plain-text paragraph, could be used for any and many types of content requests. In this case in particular, I cant't think of a tweet needing extra data but the copy body, where all links and hashtags would be, anyway.

If there's a case where we require specific data, then it'll be better to have specifc content type nodes:

  • TweetNodeRevision
  • ListicleNodeRevision
  • InfographicNodeRevision

But I can't think of any of those requiring anything but the text body.

Just like today, Revisions is where all the judging, noting and commenting will happen.

ContentNodeMedia

Also a 1-n relation to ContentNode. Would allow for revisions on media.

Field Description
Type Image, YouTube/Embed, Link?
Description Useful for early stages, like briefing and concept.
Path Image URL, YouTube URL, Link URL

Workflows

Workflows should be based on Policies. Since we'd run with generic, reusable models, we could settle on a unified worflow, like first approving copy (ContentNodeRevision) and only then getting into approving images (ContentNodeMedia).

But if custom workflows are required, then, again, we should have specific models for each ContentNode type; or at least extend them from it.

@robclancy
Copy link

I don't want to do the reusable ContentNode for other content types. I just want tables per content type and model per content type. Shared code can be done with traits. This is mainly because of eloquent and PHP making these things messy over time. Also if we wanted a feature for one revision it would add it for all and if it shouldn't. It will just end up being a mess in some way. This is also why we separated the routes for each content types and have all the components for a content type.

So we change it to be more specific. The other issue here is ContentTweets as we never plural models and database tables are already pluralized. Also since we change from ContentNode to ContentTweet we sould have issues with readability and errors with ContentTweets. So have changed to ContentTweetIndex however if you have a better name then I'm all for it.

                                     ContentTweet     ContentTweetRevision
                                   /               /
ContentRequest --> ContentTweetIndex --- ContentTweet --- ContentTweetRevision
                                   \               \
                                     ContentTweet     ContentTweetRevision
                                          \
                                           \-- ContentTweetRevision
                                            \
                                             \-- ContentTweetRevision

So when doing this first content type you need to do it standalone, think of just what it needs and do that. Then when we add a second social post type we will refactor the original into traits and interfaces to share all the code and the only part copy pasted will be the tables. As for client side it is fine to do a more generic set of social post components but I recommend doing them just to do with twitter first and then when adding the second type we can rename things to be more generic. Still needs separate routes though, so /content-requests/:id/tweets and /content-requests/:id/facebook-posts etc.

With this you need to commit often and ask questions often so you don't get stuck as I still won't be able to help much for a while. Next week I will change sleeping pattern to be online during your days so we can have a big week.

@armincifuentes
Copy link
Author

armincifuentes commented May 25, 2017

@robclancy

I'm inclined to use ContentTweetsRequest as it holds the data for the requests, specifically.

Also, since we're not doing generic models, maybe it's better to just discard ContentNodeMedia and blend its fields in with ContentTweet.

@robclancy
Copy link

ContentTweetsRequest sounds fine. I don't understand what the ContentNodeMedia is but yes less tables and more columns is generally better so adding to ContentTweet is good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment