Be honest and ask yourself how many movies you've seen where a character said in a solemn tone: “the hardest part is over.” A lot, right? However, in this case the phrase is not extracted from a Hollywood script; the previous “View” class really does the hard work of handling single and multiple view objects via the same “render()” method. However, there is still a missing piece in this schema that needs to be created, to get the earlier hierarchy of classes up and running. Yes, as you may have guessed, it’s necessary to derive yet another concrete class from the corresponding abstract parent that only handles single view objects and not composite ones. The following class, which has been called “Partial” does exactly that: (Partial.php)
class Partial extends AbstractView Trust me, I don’t want to sound like I’m bragging, but you’ll have to agree that the definition of the previous “Partial” class is ridiculously simple. It only throws a couple of custom exceptions within the inherited “addView()” and “removeView()” methods. The reason to implement these methods in that way is pretty obvious; the class only handles single view objects and therefore can’t remove or add others. Got this point? Great. So far, so good. At this stage, the hierarchy of classes required to use the Composite View pattern in a useful fashion has been completed. It's time to list the classes all together, so you can have them at your disposal in one single place for editing purposes. This will be done below, so keep reading. Showing all of the composite view classes defined previously As I said above, I included the definitions corresponding to all the sample classes created so far below. This way, you can edit their source code and add your own improvements to them. First, here’s the abstract parent that encapsulates the functionality and behavior of generic view objects: (AbstractView.php)
abstract class AbstractView // constructor // get the specified property from the view // remove the specified property from the view
<?php class ViewException extends Exception{} Having shown the abstract parent, which is seated at the top of this hierarchy of composite view classes, it’s time to list the one that renders single and multiple view objects through the “render()” method discussed previously. Here it is: (View.php)
class View extends AbstractView And finally, below you'll find the definition of the concrete “Partial” class, which is tasked with creating single view objects. Check it out: (Partial.php)
class Partial extends AbstractView Mission accomplished. Now that you have all of the composite view classes created in this series available in a single place, feel free to give them a try and see if they really can be used for building web pages by using partial sections and master layouts. Anyway, if you feel intimidated and don’t know yet how to tackle this process with confidence, don’t feel concerned, since it’ll be covered in depth in the forthcoming tutorial. Final thoughts That’s all for now. In this third part of the series, I went through the development of a concrete class derived from the abstract parent built previously, which was charged with creating simple view objects. As you saw, this class isn’t capable of aggregating new objects or even removing existing ones, so the inherited “addView()” and “removeView()” methods simply throw a couple of exceptions when called by client code. Having already created a hierarchy of composite view classes, the next step we must take is to put these classes into action. This way, you'll see how flexible they can really be when rendering (X)HTML templates. With that premise in mind, in the following article I’m going to set up a concrete example that will use all of the sample classes defined so far. Here’s my final piece of advice: don’t miss the next part!
blog comments powered by Disqus |
|
|
|
|
|
|
|