|P is for Practical|
Re: HTML - seperating design and logicby submersible_toaster (Chaplain)
|on Jul 03, 2004 at 11:45 UTC||Need Help??|
You raise a valid point, what concerns me the most with code I write and/or maintain is when architecture says that code and display logic are supposed to be seperate but you end up resorting to stuff like.
This is obviously a naff example, since $insert should be a TMPL_INCLUDE (if you talk HTML:Template).
As raised earlier , display logic within templates is seen to be a necessary evil, less important that seperating WHAT data should be rendered as opposed to HOW that data should be presented. Your code should build valid structures of data that make sense to your templating system.
What this suggests to me is that there is room in the design for a pre-output process between generating valid data and filling a template with that data. When I find myself writing objects with a data struct one way, but a method to output something that makes sense to a template system. eg
It feels like the reformatting of my object's data for a template system is NOT the responsibility of my object. There ought to be a preprocessing phase. Yet another level of complexity. This pre-processing stage is where I would expect the addition of things like odd/even line BG color changes, or turning a structure inside out to list it as entities by sorted key. For example , your method returns an hash of object references with names as keys that are valid and relevant to the current application's run_mode, you pass that data structure to a template preprocessor because you would like the data ordered by keys and flattened into an array of hashes suitable for a TMPL_LOOP. MIght look more like.
I can't believe it's not psellchecked