If you’re still not sure about the flexibility of the previous rendering application, then when I show you how easy it is to add a new “plug-in” to it, all of your doubts should vanish. As I said in the preceding section, the “plug-in” that I plan to implement in this case is a basic class that renders some JavaScript alert boxes. Its source code is shown below: (Javascript/AlertBox.php) <?php namespace Javascript; class AlertBox implements RenderRenderable Admittedly, the definition of the above “AlertBox” class is so easy to follow that it doesn’t bear any further explanation. However, there’s a tiny detail worth stressing, in case you haven’t spotted it yet. The class is effectively an implementer of the already familiar “Renderable” interface, so in theory an instance of it could be passed to the previous client rendering class and displayed appropriately. While this sounds simple to achieve, the best way to check if it actually works is to create a whole new example that injects an alert box object into the internals of the client renderer. This example will be created in the following segment, so move on and read the next few lines. Putting the “AlertBox” class to work As I said in the preceding section, below I included a script that shows how to render on screen the alert box just created, together with the two HTML widgets previously defined. Check it out: <?php use HtmlDiv as Div, // create some HTML elements // create an alert box // create the renderer and add the previous elements to it As you can see above, the script first spawns a pair of HTML objects along with an alert box, which are then added to the client renderer. Finally, the entire output is dumped on screen in a single go, via the renderer’s “render()” method. Of course, you shouldn’t take my explanation for granted; feel free to give the earlier script a try. If all goes well, you should see a div and a paragraph displayed on the browser, together with an alert box showing you a silly message. I don’t need to say that the purpose of this example isn’t to teach you how to create basic HTML and JavaScript elements, as you already know how to do that (and probably much better than me). What you need to see is that the previous alert box was rendered simply by injecting an instance of its originating class into the renderer. What’s more, there was no need to change a single portion of existing code, even though the alert box object wasn’t an HTML element itself (effectively, it doesn’t extend the abstract HTML parent). This simple concept shows quite clearly how the implementation of the “Plug-in” pattern can help to build scalable applications without having to struggle with the burden of a bad design. Armed with this background, go ahead and start using this pattern when developing your own object-oriented applications. You’ll won’t regret it, trust me. Final thoughts In this second installment of the series, I demonstrated how the functionality provided by the “Plug-in” pattern can be used for developing a fully-pluggable application that renders different types of elements on screen. In the example above, the “plug-ins” passed to the client renderer were objects that generated basic HTML/JavaScript code, and nothing else. It’s possible, however, to inject other kinds of objects with the same ease, as long as they implement the earlier “Renderable” interface. So, if you feel adventurous and want to see if this model is this flexible, feel free to develop your own renderable class and pass an instance of it to the client renderer. Everything should work like a charm. Of course, the implementation of the “Plug-in” pattern isn’t only limited to displaying a few HTML elements and alert boxes, as it can be used in all sorts of environments. To prove the veracity of my statement, in the upcoming tutorial I’m going to show you how to utilize it in the development of a versatile caching system. Don’t miss the next part!
blog comments powered by Disqus |
|
|
|
|
|
|
|