To complete the earlier abstract composite view class, we must add to it a method that allows it to render its associated template on screen. This simple method will be called, not surprisingly, “render().” Its implementation has been included below in the class’s source code. Check it out: (AbstractView.php)
abstract class AbstractView // constructor // get the specified property from the view // remove the specified property from the view As you can see above, the “render()” method is responsible for performing two well-differentiated tasks. First, it populates the view template with the values assigned to the class properties created “magically,” and second, it returns the parsed template to client code for further processing. Of course, it’s clear to see that the logic of this method can be improved in many clever ways, but for the sake of clarity I’m going to keep it this simple. Now that the development of the “AbstractView” class has been completed, it should be a bit easier for you to understand how concrete implementations of this class will be capable of rendering one and composite views through the same “render()” method. However, if this process still remains confusing to you, don’t worry; it’ll be covered in detail in the next tutorial. Final thoughts In this introductory part of the series, I went through the definition of an abstract composite view class. This class not only encapsulates the functionality of generic view objects, but defines the interface required for adding and removing the objects in question. Naturally, this capability must be implemented in some way by a concrete subclass, right? To fit this requirement, in the upcoming tutorial I’m going to create the aforementioned subclass. This should help you understand more clearly how to render single and multiple views via the “render()” method implemented by the abstract parent created before. Don’t miss the next part!
blog comments powered by Disqus |