|
|
Joined: Aug 2000
Posts: 3,590
Moderator
|
|
Moderator
Joined: Aug 2000
Posts: 3,590 |
You do a great job, and have done a great job. I have sat on my hands while you've been typing, because I didn't want to try to keep chasing the technology. Even on Unix/perl there are advances -- mod_perl, emb_perl, PHP, etc. Each of those requires a different way of thinking to co-exist, and to enter the realm of software reusability and compatibility. I have to admit I am _not_ a mod_perl expert, and my server is not really running mod_perl, because I have a big block on getting it set up right . But, all my programming is mod_perl compatible, and seems to work on other people's mod_perl servers.
<br />------<br />Here is the definition of StatINC:<br />StatINC Smpf Reload require'd files when updated APML<br />------<br /><br />BEGIN blocks <br />Perl executes BEGIN blocks during the compile time of code as soon as possible. The same is true under mod_perl. However, since mod_perl normally only compiles scripts and modules once, in the parent server or once per-child, BEGIN blocks in that code will only be run once. As perlmod explains, once a BEGIN has run, it is immediately undefined. In the mod_perl environment, this means BEGIN blocks will not be run during each incoming request unless that request happens to be one that is compiling the code. <br />Modules and files pulled in via require/use which contain BEGIN blocks will be executed: - only once, if pulled in by the parent process - once per-child process if not pulled in by the parent process - an additional time, once per-child process if the module is pulled in off of disk again via Apache::StatINC - an additional time, in the parent process on each restart if PerlFreshRestart is On - unpredictable if you fiddle with %INC yourself <br /><br />Apache::Registry scripts which contain BEGIN blocks will be executed: - only once, if pulled in by the parent process via Apache::RegistryLoader - once per-child process if not pulled in by the parent process - an additional time, once per-child process if the script file has changed on disk - an additional time, in the parent process on each restart if pulled in by the parent process via Apache::RegistryLoader and PerlFreshRestart is On <br /><br />
I have close to $1000 in apache and perl books here. Why? Because each gives a slightly different twist and/or insight to what is going on -- and I'm not even developing a "commercial" product -- just fiddling with my own websites (meaning I don't have to make any environment or user happy except me).
I'm somewhat lucky in that I started with mod_perl almost as soon as I started doing more than writing shell-scripts in perl. (or adding a formmail.cgi to my site).
I am still trying to figure it out, but as you can see, there are ways to reload modules when you make a change, and/or to make modules reloadable.
I have to admit I'm not sure what you mean by having the persistant database connection in place once the program starts, etc. I don't know enough about how w3t works to analyze that.
I know with the other programs I've run, or set up, or am working with, the "persistant" database connections are really 'semi-persistant' and apply to the process, not the cgi-call (if that makes any sense?).
I do need to dig into the w3t logic a bit more, but I am (again) sitting on my hands until the next release of Links comes out so I can start the integration in a coordinated fashion.
Templates _are_ the way of the future. it's the only way the program can evolve and upgrades be made without having to rewrite the code/application every time. Sometimes, the templates are in many ways more complex than the application.
You might need to step back a bit, and create a template parser module that just handles the objects and concepts of template parsing. Make it flexible enough so that a "template" is anything that is passed to it -- file handle or variable, or even hash. (the last one is a jump, I know, but there are possibly uses for it).
That way, you can set up "variables" to be parsed rather than having to do a file open for small templates, and internal templates.
It will also allow you to include templates and variables into the templates.
Once you have a module that does that, then anytime in the source you need HTML or OUTPUT code, you call a routine in that module, and pass it a "template" -- or variable -- to act on. This can be abstracted into the standard 3-level call by having the application call an interface module that accepts the neccessary parameters, but the subroutine called in that interface module does different things, and then loads the right template for each call.
Lets say "parse_template" is the call that actually does the work, and starts the process of fetching the template (or using a passed variable) and scanning it, replacing parameters, and passing back the filled-in string. "parse_template" accepts several parameters (depending on what 'state' the program needs to track), but it's not called directly.
Why? It may change, or need to accept other parameters, etc, so you need to provide an abstraction layer from the application. To do this, you create another file like w3t_vars.pm that holds "wrappers" to the parse_template routine.
The application will call "get_html_template_name" and that will be nothing more than a wrapper to take the "standard" passed parameters -- the template name, and maybe state information --- and pass it to the "parse_template" routine. But, inside the "get_..." routine, other things may happen, to format that call into the proper format for the 'parse' routine.
Is this making sense? The application just says "I want this string, formatted, do it." The "parse_template" just goes and does it, but the "get_html_template_name" is what takes the request from the application and turns it into the request for the parser, and returns the result. That way the only file that really changes is the "get_html..." interface file. The application doesn't have to change, and the "parse_template" file can change, but only the interface layer has to be adjusted, not the application.
Why did I digress? As I said, I have not gone into the code too deeply, but it seems from running it, and from your still straddling the "template fence" that there has to be more refinement of the parsing routines.
Will it require more "horsepower" and "system" resources? yes. But, that is getting cheaper, and it's _much_ cheaper than the human/programmer time trying to maintain each upgrade, and work out the bugs from trying to install each upgrade, etc.
you've stepped into a total redesign of the logic, and way of thinking you have maintained for 5 versions.
It's not going to be easy at first, to think in terms of "template" rather than embedded code.
but,the more you do it, the more modular the program and logic becomes, and the easier each subsequent upgrade will be.
mod_perl and modules, templates, and object code is the way of the future. PHP is embedded in the server, there is no reason why perl shouldn't be. I don't like PHP, for instance, I just hit a site that when I requested a page, it spit out the raw html with all their source code, embedded tags, etc. Big security breech. That doesn't happen with .cgi/perl. I don't like storing the program code in the output files, in the document tree.
Investing the time to synchronize and update the logic -- and your thinking -- is not 'wasteful', it's the only thing you can do. The other forum software is starting out with templates, modular/object code, and even PHP and sql and mod_perl concepts built in from the start.
I chose w3t more because of your committment to it over time, than for it's "advanced" look or features (it's a bear! ) compared with other programs. I can't afford to switch software, or to have to do my own development if a product goes out of development. Part of that has to be the costs of maintaining it, as well as performace.
This got long, and drifted through 3 different topics, so I'll end it here.
Templates are a must. mod_perl, objects, and modularity are essential. A well designed, robust, template/object parser could possibly move as much as half the code out of the application, and into a module. Add to that an SQL and database module to handle those functions in a simple, standardized manner, and the application becomes a series of short .pl files that load (or access pre-loaded) modules, and just handle user requests and get data from the database and output it to the user. Everything in the middle is a black-box .pm file.
Down-side? It means more back-end time, and less new code released for awhile. Up-side? You've rebuilt the project and future upgrades and features become easier.
|
|
|
Donate to UBBDev today to help aid in Operational, Server and Script Maintenance, and Development costs.
Please also see our parent organization VNC Web Services if you're in the need of a new UBB.threads Install or Upgrade, Site/Server Migrations, or Security and Coding Services.
|
|
|
Posts: 87
Joined: December 2001
|
|
|
Forums63
Topics37,575
Posts293,931
Members13,824
| |
Most Online6,139
Sep 21st, 2024
|
|
Currently Online
Topics Created
Posts Made
Users Online
Birthdays
|
|
|
|
