[MUSIC] In this set of lectures, we will discuss the Image Lifecycle with the addition of ImageContent. Creating images and generating scaled ImageContent. Getting ImageContent. Getting ImageContent URL from an image. And deleting an image, along with its ImageContent copies. However in this Part 1 we are just going to look at creating an image along with the scaled ImageContent. As a part of implementing this capability we're going to write a test where we pass a payload to the image controller by calling the create action where we posted the images URL. Image Controller will take care of saving the metadata part of the image and building the original for the ImageContent and invoking the ImageContent Creator to generate for standard ultimate sizes and save all files. We'll do a very laid amount of testing at this level and only check basically that this five content size is success. More detail test will be done later. So, in the specs that I've pre-populated in you get repository, I'm looking at the spec in spec/requests/image_contents_spec.rb. Overall, it's in imageContents and I initialize the overall spec with a db_cleanup context. The creation of copies, although doesn't take that much time, it's noticeable in time. It might take, I don't know, four to six seconds on my Mac to generate the four copies and process them. And so what we would like to do is be a little bit judicial, say as, to when we create them and when we can hold on to them. So I'm not going to patch the database in between each test, I'm going to let the test sections decide for themselves what cleanups are necessary. And then I had a new database cleaner context called db_clean_after. Which is just an after all then I do a truncation on overall assets basically with that says, when I'm done I'm going to clean up after myself. And if the previous context did the same then we should based be starting fresh each time that allows me to hold on to images, image sizes for some efficiency, okay. So in this first test, what we're going to do is post a document of image_props to the controller, caption ImageContent, content_type, etc. And we're going to expect to get a created status back and a pay load that contains the id of the image. All we're really going to check is that we have 5 image content available to us at this point in time. We have more test that it'll go in deeper. Since it's early it's be nice if we posted something about what we're posting to the server so that we can see that. But if you notice this except content that I have here. That's another helper class that I put into the support area. And so if you remember our images are attentionally a megger cell in size. With base64 encoding, they're about one and a half times that size. So when we go to dump any kind of a hash of properties, we have to account for that otherwise, it'll just take over our screen. It knows what an image payload document contains. And it's basically logging, a redacted form of that hash. So instead of showing all one megabyte of bytes it just give me the account of bytes that are in that hash. Okay, what probably also be nice is at this point of time we printed the response. Okay, now of course we don't expect this to be anything successful because we haven't implemented anything but it's nice to keep us on track. Okay, so in running our test, what we're doing is we're printing out the fact that we have this caption. We have this needless creator_id. That's going to be assigned on the server. So consider that to be trash. We have image_content, which has content type and 1.3 megs of bytes in the payload. What came back was the created image and then in fact was created with a URL and the organizer roles. But the problem though it went on with its business but it never created the image content. Of course not. It's in its vanilla state where it knows nothing of image content, it just ignored it as much as it ignore this extra creator_id let's fix all that. Okay, so I'm at the point where we know the image can be saved if somewhere after this that we need to know start worrying about image content. Let's start immediately and what we're going to do is instantiate our original copy from parameters that came in from the request. And here is a helper method that we still need to define. So in the area of our other whitelisting type of helper methods, like image_params and now image_content_params, what we're saying is that if you're going to have image_content. We're going to require that you have this leading image content element and inside of it require both content type and content, and then of cause white list the content type and content so we can process it. So at this point we should now have our original. And from our original in the image that we have just saved and has an id, we should be able to create new content from our ImageContentCreator that we created in the last lesson and asked it to the build_contents, standard set of contents for us. And then with those contents, let's go save it and let's use the form of save where we want it to throw an exception if it fails. And if it succeeds well, let's continue on the success path that we had in front of us when we started of assigning the user_role and saving the role. And notice, anyone of our saves are going to throw an exception. And that will roll back our transaction. So at this point if we have trouble with save it's going to throw in an exception and it's going to be handled pretty much the same as role.save so we have no need for an else block and so as long as we are passing in everything correctly doing happy path I think we should get ourselves some image content. And so when we rerun our test, we are posting our document again, getting a successful creation and then when we poke into the database we actually see that our image content has been created. Okay, we should be feeling pretty good now, right? All right, well, except for one thing. You notice in our logs, one of the things the controller does by default is to log incoming and outgoing payloads. So it's still doing the same thing in-going and out-going payloads except now we have part of our payload is about over megs worth of bit 64 in code content data. So just as much as I had that helper method in the unit test that redacted this information and just told you is how many bits this was. We couldn't do the same for the server logs, all right let's do that now. So what we want to do is go into filter parameter loging, and effectively treat our image content as if it were a password and we would like that reduced. So if we remove log/test.log and we run our test. And then take a look in our images now, you will see that our image was posted api images, and here comes the parameters and you'll see that image content is labeled filtered okay? Also notice that we didn't need to do wrap parameters on image content, because technically is not part of the image. In summary, we create an image content along with the image metadata. Image content came along with the payload when we created the image metadata and now the image controller requires that ImageContent be included with the image in order to create that image and the controller will save the original plus it will build and save four additional scaled sizes. And because of its excessive size, relative to our metadata, we need to address that. And we did that in a couple of ways. We filtered out the image content from showing up in our debug, and server logs. If we had not done that,every time we post an image, we would get another mega tool added to our server logs, especially and overwhelming our screens. I also added an additional database cleaner. One that would clean up everything after a scope finished. And what this allows us to do is create certain objects at the start of a context and reuse them across follow on tests. This is especially helpful in query tests. Where you just want to populate the database once and then run several task that query different things. Because to create new image content and then delete it in between tests, probably adds a few seconds to every test and those seconds add up. If your task take a long time to execute, there'll be less chances to run them And you want to make sure that you're able to run them often. What's next? Image Content API Lifecycle- Part II: Getting Content. We're going to continue our lifecycle discussion and expanding it to getting the content back from the image and displaying it on a browser.
