I'm also writing a large web app and, even though it's basically a monolithic CGI (don't worry- FastCGI!), I also wanted to integrate some method of expansion. I am accomplishing this with a sort of menu page where various functionalities can be chosen or decactivated and a further page where each "program module" (Not necessarily perl module) has some preferences/ configuration page (or new window?). Each "program module" is supposed to provide a different filter or different editing functionality for the data set provided. I have not yet documented how one builds such a module since it involves modifying some hashes in the main CGI script. But the basic way to link in a module so that it is recognized is through my /etc/myprog.conf file which I parse at script startup (easy enough in perl!) with keywords like 'UseModule' and 'ModulePath'. After checking that the file exists, I import it (it's an actual perl module) and call a standard function which links it's hashes with the main CGI's hashes which in turn will be displayed in a select menu on the final HTML page. While this in no way simplifies the manner in which a user can come up with his module (until i cough up some documentation), this simplifies the manner in which I am able to manage each module individually and expand at will.

This method of expansion gives me quite a few more advantages over your "create-a-new-markup-lanuage" method:

Also, as your program progresses in version, the perl modules can be morphed to C, Pie-thon, or any other language users wish to see (can you say Rexx?). If you are able to come up with a strong and basic core to your web app, the functionality can be built out of shared modules (shared among the instances of the CGI) and a version upgrade would simply entail a module upgrade. Errors and bugs can be easily eradicated by isolating and repairing single modules! I thought it through for a while and I came up with a different solution but decided the aforementioned idea would be more efficient: I considered writing a daemon that would manage a bunch of mini-CGIs that would in turn be responsible for the dbengine calls. the daemon would handle user info and the config file. But then I just defaulted to fastCGI. You might also look into some current so-called "web objects servers". Have fun with GPL!
AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

In reply to Re: expect users to program or define a simple definition language? by AgentM
in thread expect users to program or define a simple definition language? by BastardOperator

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.