>>>>> "GL" == Greg London <[EMAIL PROTECTED]> writes:
GL> I don't know how to summarize this approach in a one-liner, though. GL> Perhaps something like GL> "put the control functionality into the users data, not your script" GL> I haven't been able to consistently implement this and it seems GL> to be some vague principle I've learned the more I code, GL> rather than something I learned in school or in a programming GL> book or whatever. GL> I failed to do this in one of my recent big scripts and implemented GL> a code generating script by parsing a text config file from the user. GL> As the config file got more and more complicated, I realized that GL> I should have had the user write the configuration file in the GL> form of a perl script and provide a code generating module that GL> they use. my bad. GL> If I were to create a maxim, it would be something to the effect GL> that if you need to give your user control of your script through GL> LUT's and other data, then consider whether you should give GL> them a module and have them do their control logic in perl. GL> as your control LUT's and data structures get more complicated, GL> it might become easier to leverage perl to handle that, rather than GL> having the user munge more and more complicated data structures i have had the very same experience in stem log filtering. my first (genius!! :) approach was to offer various logical and filter tests that were driven by user entered data. stuff like 'op' => [ @args] and some of the ops were even booleans working on previous ops. it seemed great at the beginning but it always gnawed at me. (btw, that is the coding skill i trust the most, how i FEEL about code :). i just gave this project to someone who will redo it as a proper class that a user can write simple perl code to do the various filter tests and actions and not some wacko structures. it did take a while to figure out the right object design and api which would be the easiest for the user to use. but now that i have that design, coding it will be easy and much of the original code (that did filter actions) can be reused (but with a new api). sometimes it is hard to see the boundary between data driven and code driven. i originally thought data driven would be simpler for the user but it turned out i needed so much power in the filters that going back to code driven (but the api design being key) would be better. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
