Tilly,
I really do appreciate the time you took to provide these thoughts. For the moment, I will focus on the list you provided. If you have further interest in discussing what you mentioned in the preambled, I'd like that as well.

  1. Actually, I'm not so hot on prototypes myself. I misinterpreted some information in the cookbook to mean that they were required when creating a module... I asked about this in the CB one day, and have since learned that prototypes are not required for module creation. I have since dropped them.
  2. OK, I understand this, although I think I take it more as a criticism of my naming skills rather than methodology.
  3. Agreed. Although I do plan on removing the passing altogether, to allow the user to call get_* and set_* in order to remove the need shift in and set such variables. Alternately, I could just...
  4. Make these items globals and export them.
  5. Acknowledged, but largely as a issue of style. I find $$foo{bar} just as easy to read.
  6. Excellent idea. I'll put this in the todo list.
  7. Agreed, and I'll probably take errorhandler out of the structure; it was put in there to placate a coworker, and never was clear on how it would be used.
  8. I've never handled errors in this fashion, but it makes sense.
  9. I used numeric codes as a way to keep the templates clean, and because the idea is familiar to me. Additionally, I don't see support for regexes in tt2's directives, although I could replace the get_bit sub with something like match_string (string, regex_contents)..
    [% IF get_bit (error_level, 1) == 1 %] <FONT COLOR=RED> [% END %] versus
    [% IF match_string (error_string, "first name") == 1 %] <FONT COLOR=RE +D> [% END %]
    hmm...
  10. Yes, I had noticed this occuring when I had typos in modules so loaded.
  11. Noted. I really don't have anything to add, I'm not brushing you off.
  12. OK, I'll take a look at it, although I'll probably try to massage it back into an HTML table of some sort. :)
  13. This is true, too. I expected some flak on this since I realized my DBI stuff was pretty light; I was concentrating on debugging framework rather than making sure the csv got locked appropriately.
Again, thanks for taking the time to turn a critical eye to my submission. I plan on incorporating much of what you've suggested into the source code.

In reply to Re: Re (tilly) 1: Framework.pm 0.01a by boo_radley
in thread Framework.pm 0.01a by boo_radley

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.