Speed is a valid concern. But before you get to worried about it, try it the change and see if it is actually a problem. It may not be as slow as you think. And as my mom always said "Don't borrow trouble." But if speed is a problem, there are ways to move forward.
Two common solutions exist for the problem of having to open and parse too many files. 1. Use a database 2. Pre-process the files and cache the results. I'm just guessing, but I believe that you have zero interest in digging into the world of databases right now. That leaves preprocessing.
Your current method is a form of pre-processing where you are the processor. You manually convert the list of monsters in your CSV file into a group of files. Then the menu script looks into the directory and makes the menu based on the file names. When you add or remove a monster, you manually add or remove a .pl file.
Instead of this manual process, have a script that does whatever needs to happen to generate a data structure that represents your menu. Probably series of nested arrays. Then save that data structure to a file, using Storable is probably the simplest and best way since it is core and fast.
Now when you want to generate the HTML for your menu, instead of redoing the work of processing all the files, simply load the data from your file and generate html.
# Generate this by doing what you do now to make your menus. # Then save it to a file by using Storable's lock_store function: # use Storable qw( lock_store ); # # lock_store( \%menu_data, 'menu_file.store' ); # In the code you use to render your html menu, load the data from # the file using Storable's lock_retrieve function; # use Storable qw( lock_retrieve ); # # my $menu_data = lock_retrieve( 'menu_file.store' ); # Here is an example of a data structure that compactly represents you +r # menu. # # Item format [ 'Text', Link, children ] my $menu_data = [ [ 'About', undef, [ ['About me', 'About/About_me.pl'], ['About my user names', 'About/About_my_usernames.pl'], ['About this site', 'About/About_this_site.pl'], # And so forth ], ], [ 'Books', undef, [ ['Fiction', 'Books/Fiction.pl'], ['Non-fiction', 'Books/Non-fiction.pl'], ['Role-playing fiction', 'Books/Role-playing_fiction.pl'], # And so forth ], ], [ 'Fiction', undef, [ ['My Life as a Witch', 'Fiction/My_Life_as_a_Witch.pl'], # And so forth [ 'Erotic fiction', undef, [ [ 'The Angel', 'Fiction/Erotic_fiction/The_Angel.p +l' ], [ 'The Assassin', 'Fiction/Erotic_fiction/The_Assa +ssin.pl' ], # And so forth ], ], ], ] ];
This approach should lead to a couple of benefits:
- Less manual work - any number of updates can be handled by simply running the preprocessor script.
- Simple HTML generation code. You have several different ways that you represent data on your account. Each of these must be processed in its own way. My guess is that each different sort of data processor directly generates HTML. This means that any changes to your desired HTML output must be repeated in many places. By generating a standard structure you can consolidate all of the code that HTML generation for menus in one place, you make changes to the final HTML easier. Also, this approach allows you to produce multiple distinct outputs from the data structure, a possible real world example would be RDF generation.
- You can break the relationship between file names, URLs and document titles.
I am assuming that you can write code to traverse the $menu_data structure. If not, let me know and I can demonstrate the required concepts.
My comments here are based on my understanding of the following statement. If they don't make sense, then I probably misunderstood you.
Currently, the Monster directory has a .pl file for each monster. Those are loaded into the menu script.
I understand this to mean you scan the file names and use those to populate the menu.
TGI says moo