>>>>> "GL" == Greg London <Greg.London-hTC4jtLDtzoAvxtiuMwx3w@xxxxxxxxxxxxxxxx>
>>>>> 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 ------ uri-X/06uaNR9nFmbZtjAW+qKA@xxxxxxxxxxxxxxxx --------
http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
|
