On Mon, 15 Apr 2002, Puneet Kishor wrote: > > Separating layout, logic & data is a virtue in any programming > > situation [which is why HTML is such an abomination, but I digress]. > > I guess I should have clarified that that is what I believe in already > (the separating part, not necessarily the HTML as an abomination part).
Well the problem with HTML -- and the reason it's such a &(&$%%&()^ pain in the ass to get things to work well on different browsers -- is that you have an intermingling of structural elements (body, head, table), semantic elements (emphasis, strong), and style elements (i, b). Scattershot, in other words. XML is supposed to fix this by forcing you to have one document that only has data -- semantic elements, really -- and you pair it with some other document to generate a strategy for presenting that data -- stylesheets, for example. XML is hardly perfect, but it's a step back in the right direction, in that it separates data from layout -- as should have been the case all along. > now, I can't really use a template in the "form letters" kind of sense. > I mean, take month... months can have 28, 29, 30 or 31 days, they would > be put in a table 7 across but sometimes 4, sometimes 5 rows. Well that just brings up another programming rule of thumb (two variants): "Be generous in what you accept, and strict in what your produce." or "Be liberal in what you accept, and conservative in what you produce." One of your jobs, as a programmer, is to make these sorts of formatter functions dynamic & robust enough that they can handle edge cases like this well. Maybe you assume that all months are five weeks & 31 days, and just pad as needed (that's what paper calendars seem to do). > there are many occasions in which the display is determined by the data > received and maybe certain other conditions. At those times should I > bung the data inside the sub so it spits out a preformatted chunk of > displayable code, or should I get the raw data out of the sub and then > apply the logic. Well that's the big question, isn't it? My instinct is to have good control over your data structures -- or wrap 'em up in objects and pretend not to worry about such messy details -- and set up your functions so that they can emit & receive these structures as cleanly as possible. Somewhere between the two options you suggest here: rather you just have one element that knows how to generate a certain kind of list or hash, and another that knows what to do with one of those variables when it sees one. But this is all very hand-wavy & theoretical -- in the end you just have to try it against the problem[s] at hand, and go with whatever seems like the cleanest, most efficient, most elegant, or whatever solution to things. > I also learned that instead of putting a bunch of print statements, I > should make a variable out of the display code, and then return the > display variable. Yeah, that's not a bad idea, because it plays into the idea that certain kinds of sub are just data processing units, and shouldn't be burdened with formatting their results -- after all, maybe you want to hand those results off to another sub, or an HTML post-processor, or make a graph out of them or who knows? As long as the data processor processes data and does so reliably, leave it be & let other components do that work. > That is a good summary, no? Yep :) -- Chris Devers [EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ "More war soon. You know how it is." -- mnftiu.cc
