On Mon, 15 Apr 2002, Alex S wrote: > Chris Devers wrote: > > >>If yes, how do I accommodate repeated poking of the sub which > >>repeatedly returns data in a predictive display format? iow, do > >>I violate the above premise by making the sub return the display > >>info as well as shown below? > > > >Well if the display info is the data, then there is no conflict... > > I guess it depends on the definition of your subroutine.
By that statement, I was getting at data formatting subs -- ones that say take a data structure prepared by some other funtion, and format them in a regular way. Not sure how well I got that across though... :/ > Maybe I'm not following what you mean, but usually you can keep the > display functionality fairly separate. Yes. Separating layout, logic & data is a virtue in any programming situation [which is why HTML is such an abomination, but I digress]. > Often it's good to go with a template system, especially with web based > apps, as you can abstract not only the concepts, but the files too. > I'm a fan of Template Toolkit (Template.pm). Yeah, that's what I was getting at, though I had HTML::Template in mind. The thing I like about H::T -- as I've used it in the past -- is that it does a nice job of helping you break up any given problem three ways: the data, the presentation, and the logic. So for example you have your SQL store, and a DBI wrapper that extracts data from the database, and a Perl script that glues it all together by taking the data, pumping it into appropriate data structures, and then populating the template with that data structure. . The three components/aspects are nicely segregated, and you can have different people or groups working on each components (a DBA, some web designers, the programmer[s]) and for the most part they shouldn't step on each others' toes, because the roles are well defined & nicely divided. I've heard nice things about other templating systems, including TT and Mason, but it seems like the others tend to put more of the logic with the presentation, as compared to H::T. It's all taste & preference though -- the important thing isn't so much where the lines are drawn, but *that* the lines are drawn. > But I'm also a believer in short subroutines... Oh sure. Save typing, reduces typos, and hey you never know when it might be useful to bulk up the task represented by that sub (add debug output, or logging, or what have you). Keep things as modular as possible. One of the rules of thumb my programming classes taught was that any function longer than a page or screen or so might be worth breaking up. It's possible that part can be pulled out, abstracted, and used elsewhere. If nothing else, as you say, it can be more readable that way. I'd go on, but we're in strong agreement here and you make a lot of interesting points that I can't add much to. -- Chris Devers [EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ "More war soon. You know how it is." -- mnftiu.cc
