UBB.Developers Forums General Discussion Suggestions and Feedback Template Experiment

I just heard back from CIHost with the excellent news that they have installed FastTemplate on my server as I requested! I was most impressed and even better - when I went to check with perldiver, I discovered that mod_perl is also on there!

Would you recommend using mod_perl with FastTemplate? Now I can try it, I don't want to blow myself up. []/w3timages/icons/smile.gif[/]

[]http://www.amdragon.com/images/eileensig.gif[/]

I would guess that they will not allow you to run under mod_perl. mod_perl is a memory hog, and usually requires a dedicated server to run it, which is why most hosting sites will not allow you to use it on shared boxes.

But, good news on the FastTemplate[]/w3timages/icons/smile.gif[/].

Ummn. If they won't let us use it, I wonder why they installed it, then?
I think I'll ask them what the position is...

[]http://www.amdragon.com/images/eileensig.gif[/]

As much as you like to hack on WWWThreads it might not be a good idea for you[]/w3timages/icons/smile.gif[/]. Under mod_perl, anytime you make changes to any of the modules the webserver needs to be restarted before those changes will take place. If they did allow you to run under mod_perl, you would have to ask them to restart the server anytime you changed one of the modules, and being a shared server they probably wouldn't want to do it too often[]/w3timages/icons/wink.gif[/].

Whoo-hoo! That's the deal-breaker - I will definitely give mod_perl a *very* wide berth. []/w3timages/icons/crazy.gif[/]

[]http://www.amdragon.com/images/eileensig.gif[/]

I don't think that is true. In fact, that is the first time I've heard it.

The difference in mod_perl is the interpreter is embedded in the apache process, so there is no overhead/load time for the perl interpreter.

Mod_perl scripts can terminate like any other script, but they have the advantage of being able to stay "in memory" waiting for the next request. For that reason, they have to follow certain rules.

When starting the apache server, you _can_ pre-load modules into the start up, and avoid the penalty of loading them later, but I've never heard of having to restart the server if a module changes.

I checked the mod_perl FAQ:

In reply to:

---

Do I have to restart the server when I change my Perl code?
Apache::Registry checks the timestamp of scripts that it has loaded and reloads them if they change. Other handlers and library modules are not automatically reloaded by mod_perl, but you can use the Apache::StatINC module to do this for you.

---

So all you need to do is a bit of house keeping, and you gain a tremendous (awesome) speed and performance boost for many types of scripts -- database access scripts especially.

Interesting. If I decided to give it a try, what kind of 'housekeeping' would I have to do?

[]http://www.amdragon.com/images/eileensig.gif[/]

Hmm, we run mod_perl at work, and I ran it here for about 8 or 9 months before the multi-language feature was added, and I could never get a change to take place until restarting the server. I've received a number of posts on this as well with users having the same problem until they restart it.

Heres one old thread that I found that had the same issue:
http://www.wwwthreads.com/perl/showflat.pl?Cat=&Board=questions&Number=1631

I imagine if you don't preload them, then it might be different. But, with WWWThreads you have to preload them because in order to run properly it has to setup the persistant database connections upon server startup.

But then again, maybe I'm doing something wrong. It's been known to happen[]/w3timages/icons/smile.gif[/].

The "housekeeping" I refer to is following the "rules" of mod_perl. Start by nosing around the perl.apache.org site. PERL is even worse than "BASIC" for encouraging bad programming habits, and the first thing you should do in writing programs is "use strict" and try to get the programs to run under mod_perl. If you can, then you've declared all your variables, you've given thought to scope and allocation and deallocation of processes and threads.

I think I'm going to ignore Mod_perl for now and concentrate on the templates...

[]http://www.amdragon.com/images/eileensig.gif[/]

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.

Code

<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.

This makes fascinating reading. I don't pretend to underderstand a word of it but it certainly doesn't make me any more eager to make the switch to templates. It looks as though w3t would end up being a totally different program. The big appeal of w3t for most of us here is I believe that the code is so logical, clear and easy to understand. All these changes you propose take it further and further away from that with every step.

Just out of curiosity, what is the "the other forum software" that "is starting out with templates, modular/object code, and even PHP and sql and mod_perl concepts built in from the start."?



[]http://www.amdragon.com/images/eileensig.gif[/]

Eileen, I think you misread it. The proposed changes would make it easier to modify, and to maintain, since each function would be in an easily callable function -- a function that could be changed, modified or upgraded without affecting the rest of the code or application.

What has to be done is to look at w3t as a collection of objects, and visualize which objects are containers, and which are components.

For instance, a "message" would be an object made up of the various parts of the database record. A thread would be a collection of "message" objects.

The smallest nugget of information that would generally be requested would be a single message.

There would be a template for that object.

Those objects would be strung together into a thread, which is a part of a page. Thus, the "page" would be another object into which "messages" would be inserted.

Anyway, those closest to the program are those who will find it hardest to grasp the changes. But, they will also find the changes a breath of fresh air -- perhaps even freeing from the drudgery of maintaining loads of code. The "static" code is packed into modules, the semi-static code is put into the .pl files, and the changeable code is put into the templates and interface file.

There are many forum products out there. Sporum, phorum, UltraScript2000, etc. A quick check of cgi-resources.com will yeild many others.

They suffer from the problem of being "clones" and not having a mature, stable, development base.

That was the advantage of w3t. It's history.

w3t is in need of a modular/template rewrite. Otherwise, it will lose it's advantage to the newer programs that are easier to install, maintain and upgrade. They may not be "better" programs, but the "cost of ownership" will be lower.

Remember, I chose w3t over the others. The question is -- in 6 months, if I had to make that choice again, would I make the same one?

I found the modifications frustrating, and each upgrade a major waste of time -- literally. Making the same code changes again and again. Most of them were HTML changes that would have best been in the templates -- I could have just replaced the code files, and been good to go.

It's a lot easier to replace a wwwthreads.pl file with a new one that uses the old templates, and requires no changes. Same goes for each of the "modules" and scripts.

Anyway, fortunately for me it's not a life or death situation to have a certain forum. It's been a test, but will become more important in the near future. The _most_ important thing is how well I can integrate it into my site, and with SQL and PERL I should be able to do that -- but without templates, digging into the code makes it more difficult.

I think it's essential for w3t to evolve. The great thing is that the direction it's evolving means someone who starts to install it today, and work with the templates, may not have to hack into the source code at all to keep up with the updates and upgrades ever again. Copy the new .pl scripts over the old ones, update a few templates, and everything is now "upgraded" with no editing or errors.

Ok, let me ask you this then. I am guessing that you have looked at the devel version of 5.1 at least a little bit, correct?

Do, you feel that this is the proper way to go about it, or do you think I need to do some more fundamental rewriting of the base code?

I'm asking because I really would like to get some feedback on the current direction of 5.1 from various users before continuing to put time in this only to find out that I will need to rewrite again later. If I'm going to have to do some basic rewrites, I'd prefer to do it now[]/w3timages/icons/wink.gif[/].

What you are doing is trading maintainability for minor performance gains.

The embedded html creates a real problem with maintennance,and upgrades -- which you release at a regular rate.

The more features you build in, the more bloated the code will become, and you start to have performance penalties in that area as well.

There has to be a balance between core-features and user-defined modifications, and a way for users to add them in as needed.

There has to be a way to take all the user modifications out of the basic code, so that the display options, and such can be carried over from one version to the next.

>>The embedded html creates a real problem with maintennance,and upgrades

No, it doesn't - not when you use something like Araxis Merge.

Scream already has a pretty good modular system in place using the vars and theme files. This works nicely for me without obscuring the logical flow of the code and can no doubt be further developed to cover new features as they are added.

Tell you what - why don't you write the version you envision. If it's as good as you say, we'll all use it and you'll make a fortune. []http://amdragon.com/images/icons/devil.gif[/][]http://amdragon.com/images/icons/grin.gif[/][]http://amdragon.com/images/icons/clown.gif[/]

[]http://www.amdragon.com/images/eileensig.gif[/]

Well, it's a bit more than that. To properly use templates the varying languages should be in the templates as well. The way I was going I had to use the language files and then put them into a template variable and then parse them. Also, because there are different ways the user may be viewing the program it added alot of complexity. Plus various other things.

To properly use templates will require a rewrite of alot of the existing code which I'm not saying I won't do, I just won't do it now[]/w3timages/icons/smile.gif[/].

We're still missing a few glaring features that really need to be part of the base code before I go about tearing into it and rewriting large chunks of it. If I had a team of developers it might not be so bad, but it's just me so I've got to use my time wisely.