There's more than one way to do things | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
G'day Discipulus, The title of your post struck a chord: I went through a similar design dilemma a couple of years ago. Although adding the data to the module code seemed like it would work, mixing (mostly static) code with (potentially volatile) data went against the grain. The solution I came up with used File::ShareDir to access the data files at runtime. Its companion module, File::ShareDir::Install, was used for installation. File::ShareDir::Install is used in Makefile.PL. It is not used or required in any of your runtime modules. The documentation has details and it's fairly straightforward. Here's a very rough, ASCII-art, UML representation of how I used File::ShareDir: +-------------+ [compose] +----------------+ | ParentClass |<>----------| File::ShareDir | +-------------+ +----------------+ A A [inherit] | | +-----------+ +-----------+ | SubClass1 | | SubClassN | +-----------+ +-----------+ ^ ^ ^ [manifest] | | | +----------+ +----------+ +----------+ | <<file>> | | <<file>> | | <<file>> | +----------+ +----------+ +----------+ The File::ShareDir - DESCRIPTION discusses some of the bad ways to tackle the design; e.g. using giant data structures or adding data after __DATA__. It then has: "The problem to solve is really quite simple. ...". I hope that's enough to get you started. I have to get back to $work :-( — Ken In reply to Re: Module design for loadable external modules containing data
by kcott
|
|