Subtitles of the Movie

One final thing we want to look at when we talk about shared objects is the ability to share your objects across multiple Flash movies within your own domain or your own website. A couple of things to keep in mind are that number one you cannot access the shared object from a different domain name if your Flash movie resides on your web server. So there is no possibility of name conflicts. For example, looking at our creation routine here, the 'getLocal' if we call our cookie sample here cookie and another programmer on another web site called their shared object cookie and the user access both our website and the other developer's website there will be no conflict. Because the shared object first stores by the domain name which was referenced, then it stores by the path that it was referenced and then it stores the name of your shared object. In this case cookie sample. So if I create a cookie and I reference it from my Flash player on my local website, the user before its stored in the hard drive, will store in their cookie a domain tag, then a path tag and then finally my cookie name. So this can be both good and bad. For instance let's say that I have the tag http://www.mrflash.net/sample.swf and I have the same thing a couple of different paths, let's just replicate this here; and ok, as you can see these are all the same domain. So my cookie will store as mrflash.net. Then the first sample swf file would store in the root structure or this is the path that it would use, the root path. The second one would store in slash flash; that would be its relative path. And we'll look at the third one here, which would be Flash movies. You can see this because wherever the swf file resides that's where the second parameter, the path, will be stored by the shared object. So in another words there is no way that my sample swf file, if I use cookie sample as my shared object, will conflict with this swf file in the root because each one of these is stored not only by domain but also by the path. So I can actually reuse cookie sample in all three of these examples and they will be unique references. That's not always good. Let's say my website has several different swf files but I only actually want one shared object to be shared across all the different movies. The way you have to look at this is this path means that it can locate and reference shared objects in the root only. This path means that it can locate and access shared objects in the Flash directory as well as in the root directory because it is higher than those in the list. The third one can access shared objects in the movies, Flash movies' directory, in the Flash directory or in the root directory. But again remember that the one that was created in the root cannot access any of these shared objects. So there has to be a way or method that we can tell the shared object to store it in the common or root location and that's exactly what we can do. The get local method accepts two forms of input; the first one is just the reference to the cookie name, in this case that's what we've done here. The second one is in reference to the path itself. So if we wanted to assign a shared object with a universally accessible path the best way to do that would be a comma and put root in there. What that means is that if sample dot swf file had this exact line in it it would look in the root for its shared object. And if the one in the Flash location sample swf in the Flash directory had the same line it would also look in the root as well as sample swf in the root, it would look there as well. So in essence you've taken what could be a mess of cookies everywhere and you've broken it down into a single cookie, which would be in your root directory. That's the way you would handle multiple movies in a single website that wanted to share a single shared object. t's the way you would handle multiple movies in a single website that wanted to share a single shared object.