Later this month I’m going to start migrating my personal framework over to 5.4 (I intend to eventually publicly release it - but work keeps delaying things). One of the first structural changes I am going to play with are traits. I’d like to discuss what I intend here because the concepts of traits and grafting are still new to me.
For reference - The PHP Documentation on Traits
One area in my project I see this as useful is the view section of my code. Currently all of my template handling classes descend from the responder class. While things aren’t ugly, they aren’t as straight forward as I’d like. Here’s an abbreviated look at the current inheritance tree sufficient to illustrate the problem.
abstract Responder extends ArrayObject
HTMLResponder extends Responder
PageResponder extends HTMLResponder
JavascriptResponder extends Responder
StyleResponder extends Responder
Here’s the thing. HTMLResponders parse phtml templates into strings - they do not usually need to have a full page response. I’m inclined to think not carrying that ability will - at the least - make the code easier to read.
So this is my thoughts on a replacement.
trait HTTPResponder -> holds methods for transmitting the data over the HTTP protocol, which is the most typical. Eventually I can write a SAPIResponder and have both fulfill the requirements of a Responder interface.
Template -> A class for handling html templates
TextOut -> A class for Text outputting - foundational to javascript and css responses since neither have any phtml template parsing responsibility.
HTMLResponder extends Template uses HTTPResponder -> for normal request responses.
XMLResponder extends Template uses HTTPResponder -> for AJAX responses
JavascriptResponder extends TextOut uses HTTPResponder -> for straight JS responses.
StyleResponder extends TextOut uses HTTPResponder -> for CSS
FormTemplate extends Template -> A template for form object management. If it’s part of a larger page we use this object, otherwise it’s sister:
FormResponder extends Template uses HTTPResponder
Thoughts?
Note - part of the reason for this (which lastcraft influenced me heavily on) is to further reduce the scope of an individual code block. During testing traits can be bound to mock objects to be tested on their own, then the tests of the objects composed of the traits can be ran. The goal is to keep the dependency chain as short as possible.