Previously, PPH was a base class for a family of concrete instantiations. The concretes are now dead. But the instantiation point for them, in cart_ui.ctp is still in place. It just make PPH now.
This is not great. PPH should be prepared by a controller, like every other helper.
The inheritance/factory strategy started breaking down when the new CartItem blurb and options fields were created. The concretes were not so necessary then. Later, as code was developed, it was discovered that the summary/detail values for cart items that were supposed to accumulate in a property of the parent class (PPH) DIDN'T accumulate. Each concrete had it's own parent so the accumulation failed.
Probably, the concretes will be needed for some tasks (like generation of edit links for cart items). If so, then PPH should hold a collection of the possible concretes as callable objects.
If the need for code variants is low, maybe just some methods with switches will do the job.
Previously, PPH was a base class for a family of concrete instantiations. The concretes are now dead. But the instantiation point for them, in cart_ui.ctp is still in place. It just make PPH now.
This is not great. PPH should be prepared by a controller, like every other helper.
The inheritance/factory strategy started breaking down when the new CartItem blurb and options fields were created. The concretes were not so necessary then. Later, as code was developed, it was discovered that the summary/detail values for cart items that were supposed to accumulate in a property of the parent class (PPH) DIDN'T accumulate. Each concrete had it's own parent so the accumulation failed.
Probably, the concretes will be needed for some tasks (like generation of edit links for cart items). If so, then PPH should hold a collection of the possible concretes as callable objects.
If the need for code variants is low, maybe just some methods with switches will do the job.