We're not going to refer to ThingImages globally,
we're going to refer to them scoped either below things or images,
and we'll start out referring to them under things.
All right, when we specify the resources below things,
what I'd like to do is only expose index, create, update, and destroy.
That's almost the same of what we've said here except we're not including show.
So I probably could have added except show, but I chose to do it this way.
And then, although it's through things that we're going to manage ThingImages,
like deleting them and editing them, it's going to be through images
that we're also going to be able to create them, and get them.
It'll make for a fairly consistent interface if we do it this way.
What ends up happening is the create method that gets mapped to a post,
that gets mapped to a create method in the thing_images controller
will also have that same method exposed under images.
So, we can link from things to images and images to things.
And we can get our links through our images and
we can get our links through our things.
However, depending on what perspective we come from,
we're going to want to see the information differently.
And then just to make sure that we've got some decent functionality in place,
I'm going to add this additional method, where we're going to get not only
what are we linked to, but we can also get what could we be linked to.
If you remember that one query scope of not linked,
this would be a URI that gets us to the result of that query scope.
So primary management of thing_images is under things,
selective methods of thing_images is below images.
And if we run rake routes and I've gotta scale it down a bit,
that if we're getting to thing_images through image, it's image_thing_image and
if we're getting through thing_images through things, it's things_thing_images.
As ugly as the shorthand naming is to say thing twice, it actually ends up being
more sane in the end because we have two ways of getting to it and
it's very clear when you see, we're coming from the image side of things or
we're coming from the thing side of things.
And these are helper methods that are only exposed inside of Rails and
probably the most that you'll ever see of them is in our specs.
But you'll notice that when we come into the thing_images,
when we come from the image side the image_id is in the URI.
And when we come from the thing side of the house, the thing_id is in the URI.
So if we're ever going to create a link through images,
then thing_id is in the payload and image_id is in the URI.
If we're ever going to create a thing_id from the thing side,
then thing ID is in the URI and image_id is in the payload.
If we go into the controller, I'm not quite sure why it didn't create the stubs
of those methods that I specified, but it's easy enough for us to create them.
So one of the things that we want to take care of is wrap_parameters.
If a thing image comes in the mail and it has an image_id, thing_id, or
priority, we want to copy that down under a thing_image element.
And while we're thinking of such things, let's go ahead and
create a thing_image_create_params helper method that's specific to create that will
require that we have a thing_image document and inside of it have
an image_id or thing_id depending on which URI you come in on.
So in the wash Rails hides whether we're getting image_id
from the body or the URI, and he just says in the params, here it is.
So if we can't find image_id at the root level,
which would mean it's in the URI, then require it to be in the payload.
Or if we can't find thing_id at the root level in the URI,
then require it in the payload.
And then, of course, permit priority image_id and
thing_id to come on in when we create our thing_image.
And then we want to have some before actions.
A get thing and a get thing image, and they would go as simple as that.
So we're going to assume with parameter key for the thing is going to be thing_id,
and the parameter key for the thing_image is going to be id.
So before the following actions, index, update, destroy, we're going to
be calling these methods and if they have trouble, they'll throw an exception and
the application controller can pick up on the recovery.
And then to finish out this private area, we have update parameters.
Notice I expanded the name.
Instead of calling it thing_image_params,
it's, well here are the parameters that are appropriate for a create, and
here are the parameters that are appropriate for an update.
Expressing image ID or thing ID is not appropriate for
an update, only changing the priority is appropriate.
And then of course where would we be without authenticated user.
We only require authentication from methods of create, update, and destroy.
Methods like index does not require authentication,
will allow anyone invoke the method, but as you'll see down the road
we'll actually add extra processing if they happen to be authenticated.
So there'll actually be two ways in which the method will act,
whether it's authenticated or not as we get further on in the module.
All right, so index is implemented through some query scopes, and
we just finished going through that, so that should look pretty straightforward.
Then we add image_things, coming from the image perspective, what things are linked
with this image and included with that data, please include the name as well.
And then to include some additional functionality,
what kinds of things are not yet linked to this image?
What things out there are not associated with this image?
And as I said earlier,
this is a URI that exposes the result of the not linked query scope.
So next, we'll define the create method.
It's got a bit to it.
The fact that we can have our parameters coming from two different URIs adds some
complexity here.
So bring in the create parameters, and if anything's missing,
it will throw in an exception and will be caught.
But in addition to that,
we need to throw in some URI properties, and we're taking care of that.
And then after we have done error checking that says have you expressed
the information we care about, we now need to worry about, is it valid information?
Like, what if you've expressed a thing_id that doesn't exist?
