UBB.Developers Forums General Discussion Suggestions and Feedback Template Experiment

This thread is continued from http://www.wwwthreads.com/perl/showflat.pl?Cat=&Board=wishlist&Number=16894

Over on the devel site I have converted a couple of the scripts to templates. Most of the functions from w3t.pm that print out HTML are finished. I've also finished with wwwthreads.pl and postlist.pl.

This seems to be working very nicely. It does require several templates for complicated scripts, like postlist.pl requires 5 different templates, with 2 of the templates having 4 variations, but this will probably be the exception instead of the rule. wwwthreads.pl required 5 templates but there were no variations of any of the templates. The majority of the other scripts will probably only require one or two. It might sound confusing, but it's not that bad.

Anyone interested can go look at the devel site at http://www.wwwthreads.com/cgi-bin/devel/wwwthreads.pl. Take a look at wwwthreads.pl or postlist.pl, view the source and you will see where each template begins and ends as I've commented the templates for this purpose.

I've also symlinked the templates directory if anyone wants to take a look at the actual templates to see what they look like. You'll probably need to again view the source of these as when you click on them your browser might try to display them. You can view the templates at http://www.wwwthreads.com/templates.

Also, at the bottom of the template directory listing, you'll see the README file that will be included in the templates directory if you care to read it.

Feedback appreciated.

Edited by Scream on 6/8/00 03:28 PM.

Wow Scream!

This is excellent!! I am looking foward to using templates instead of having to mess with the perl code. One suggestion, as far as the name of the templates go, could you end them with a name that describes what html they output and not just a number? I really like it []/w3timages/icons/smile.gif[/]
Mike

Scream,

The templates look excellent!! Will be much easier to fool around with the design of the forum - how far do you plan to go with the templates? All files? Just the major ones that are most commonly used, or??

Thanks!

Muhammad Chishti
Creative dIRECTOR
[:white]http://www.imcuniverse.com

I originally was being a bit more descriptive, but then the name of the templates ended up being very large. That's why I went with numbers and then in the README it explains what each template actually prints out. I'll see if I can come up with some descriptions that will keep the template name down to a decent size, but can't guarantee anything.

Edited by Scream on 6/9/00 09:17 AM.

The plan is to do every file in the user's section. The admin section will remain the same.

Scream,

will it be possible to have different looks for the categories? I would love to have the chance to have different styles in the categories.

Carsten

--
Carsten Müller, Hamburg (Germany)

Not at first. That's a feature that various people have asked for. Templates make this possible, but it would be a bit too complex for starters because I still don't know what type of issues or problems templates are going to create on various files. I'm just starting out on this so I don't want to promise too much before I know what I'm doing[]/w3timages/icons/wink.gif[/].

You know, Sony Music does this somehow... but their forum is quite custom it seems.

Muhammad Chishti
Creative dIRECTOR
[:white]http://www.imcuniverse.com

It looks very promising.

Two priorities, I think.
1. Cross-browser compatibility.
2. Very short names - for speed (plus the explanatory README).


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

Sorry for being the 'odd one out' but I think it's way too complicated.. Might as well edit perl directly...

May I suggest you try something like 1 per script... where you have tags for repeating sections.. e.g. (tags shown as '{' and '}')

postlist.pl example:

Header info goes here

Header row info for table
{ITEM}
Formatting for each
{/ITEM}
End of table stuff


The {ITEM} {/ITEM} would repeat for each post that existed in the forum. This would make the templates look very 'real'...

Don't think of this as a bad remark on what you've done.. but as a positive comment. I admit I would probably give up myself :-)

My idea does have one drawback.. it's not possible for individuals to specify different templates for different parts of the same pages. T.b. honest.. I don't think that a web site colours are the key to its success.... People go to web sites for what they offer... Customization of the kind 'what information you want to see' is good.. - Therefore.. for any 'choose your skin' options... please make them optional (i.e. admin can disable)

Sebastien.



[:red]Sebastien Lahtinen
[i][:white]www.chatsplat.com
[][email protected][/]

Scream,

I think this could work very well. One thing that I'm concerned about though--will this have any significant impact on server load? It seems to me that at the very least, each perl script is going to have to open one template file, parse it, and display the results. Will this be too minimal to really make a difference either way?

I think the template concept will always have an impact on server load... Maybe they can be compiled into a better format?

Top performance-wise would be to make a system which rebuilt the CGI.. but that would make it hard to edit the CGI which is something people like me want to do...

seb


[:red]Sebastien Lahtinen
[i][:white]www.chatsplat.com
[][email protected][/]

It may seem alot more complicated, but even though there are several templates per script it will end up being a lot easier, especially for PERL novices. The reason being is without templates the HTML is buried in ifs and elses, and it's spread out over various portions of the script. With templates all of the HTML for that portion of the script is in one place.

Your thoughts about 1 template per script is something that I had wished for as well. But, unfortunately, it's not the way the FastTemplate module works. Maybe someday I can write my own to do something like this. It's highly possible, because I never really thought there was a chance to do templates period a couple of weeks ago.

Very good question, and I share your concerns. Once I get a few more scripts done then I'll do some tests and see what type of load impact this has. My *guess* is that it won't have too much of an impact, because it does the parsing in a singular regular expression. Also, using templates cuts down on some of the code complexity.

Once I get the template version done I'll put it out in beta mode so people can test it before making it a general release, so I can get more feedback on it.

Please make it easy to put the templates back into the scripts then.. i'd rather have them in perl.. Will this be possible?

Although my idea would make it complex.. it wouldn't necessary be that hard as templates are pre-built.. so you only edit them at novice level

ALSO.. please add the subject to the "e-mail any replies to me" option... At the moment it has url + text.. no subject

seb


[:red]Sebastien Lahtinen
[i][:white]www.chatsplat.com
[][email protected][/]

That wouldn't really be possible. The main reason being is that there are different templates for different portions of the code depending on the user preferences.

Don't get me wrong. I'm not going to try and shove templates down anybody's throat's[]/w3timages/icons/wink.gif[/]. But, using templates has been the oldest and most requested feature wishlist by potential and existing customers. So, it's one of those things that if it works and the majority of users want it, then it'll go in. If the majority do not, then it won't and it will have been a big waste of my time[]/w3timages/icons/smile.gif[/]. Either way, I've got to at least try because so many have asked for it.

People want templates as it makes customization easy. I agree with that, and I think many will accept your system.

My hope is that I can keep up with new things in w3t but still have it in perl (assuming they aren't all single templates).. It's a personal preference and I wouldn't expect you to keep it there for me... but i don't think it's that hard to put it back like that if someone like me wants.. and once someone does it.. other people can just copy that script :-) (there are some people who want it in perl for efficiency reasons ANYWAY)

seb


[:red]Sebastien Lahtinen
[i][:white]www.chatsplat.com
[][email protected][/]

The system looks promising. One question for now, does this template system parse templates for SSI calls? It may not do so initially but I've seen it in other template based scripts, and I think it would make it a lot more easy to blend W3T with other dynamic areas of a site.

This is a thought I had when I made my first post on the subject, so I'm glad to hear someone else mention it.

If a good system could be put together, we could have the best of both worlds--easy HTML customizing through templates, and maximum system efficiency by cutting the templates out of runtime compilation.

It would be more complicated to put this system together for Scream, but it's something to think about.

I've been looking at this hack that allows SSIs to work within CGI-generated output:
http://www.wwwthreads.com/perl/showthreaded.pl?Cat=&Board=custom&Number=15791 and wondering how/if it could be incorporated into the new template system. Or is that already covered?

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

Scream, Just for information and certainly not to put you under stress: any idea on some deadline of the beta release?
I am so impatient to play with it. []/w3timages/icons/smile.gif[/]

Not real sure at this point. I've almost finished with the hardest scripts, (showflat,showthreaded,postlist,wwwthreads, etc). Once I get done with the tough ones I should have a better idea of what type of timeframe it will be for the beta. Just don't want to open my mouth too soon and then run into some complications that will delay the release.

Been thinking about this a little more. Since I really don't know what the general response will be to the templates, I don't really think it would be wise to spend alot of time moving every script over to templates.

I have finished the main scripts that are used the most often, (wwwthreads.pl, postlist.pl, showflat.pl and showthreaded.pl). So, at this point I think what I will do is release a beta within the next week or so. This way I can get some feedback before moving on with finishing all of the scripts.

This is a wise strategy, at my point of view.

I do not see why templates will not have acceptance. If the default templates recreate wwwthreads as you ship it now (in other words, templates will reflect the actual wwwthreads look) there should be nothing to fear. If the customer want further customization, then the templates are there, ready to be changed. The other solution to not having templates is to edit every script, one by one, manually and loosing the changes on the next upgrade, which one is better? To be honest, the actual look of wwwthreads is not that great and I have seen people who purchased the product made little or no changes to it, which I consider it lame (yeah, I can see the flames already).

The lacking of templates is what is holding me back from buying wwwthreads. And I think that if you are going to implement templates, you should do it all (all scripts) or nothing. There is nothing more annoying than a work half done.

Cheers!

The main reason I'm thinking of releasing an early beta for testing the templates is because there is some concern of CPU useage. While I don't think it will be an issue, I can't say for sure until we actually get it into testing.

And also, what is done so far comprises the majority of how the program will look. All of the headers, footers, menus, etc have been moved into templates, along with the heavily used scripts. Naturally the rest will need to be finished, but this would probably give a good indicator for everyone to test to see if it is worthwile.

Of course I can do this however the majority wants it. I can just go all out and finish all of the front-end scripts and then release the beta, or I can release it early. Just let me know.

Edited by Scream on 6/26/00 02:02 PM.

Early release, please!

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

Me too. Early release, please!
Hope this week? []/w3timages/icons/smile.gif[/]

Finish first. We can stop behaving like kids for a while, we promise. Just finish it, we can wait...

What ever happened to the idea of throwing in the best hacks around (e.g. the private messages "Outbox" and "Read Receipt", inline images etc.)? Are you still planning on doing this?

Yeah I still plan on doing that. My apologies for jumping ship and working on the templates first. The reason being I never really thought templates were possible and this was probably one of the oldest requests for the program. One way or the other, if the templates work for everyone or if they don't, the inclusion of the hacks will be next.

Ok, what I will do is release a beta or dev release, so anyone can test the templates, and then I'll just keep working on them to finish up with them. This way it won't delay the progress of them if it works out, but anyone who wants to will still be able to play around with them.

I will try to get this out today, but don't know if I'll be able to for sure. Leaving for a few days to go to Victoria, BC for the holiday weekend.

I've been using templates in various programs for well over a year, and I'm glad to see that this is happening here. This program was a real bear to modify, and each release rquired the same mods over and over. Templates are a way of keeping the look/feel of a site but still upgrading the back end code.

One thought.

Many of the templates are very short, but they still require an I/O operation.

What about creating a "template file" for most of the short code.

This would create one I/O operation per script run, at the expense of a little memory. Most of the templates are showing up as 1K, which means you could probably realize a significant advantage by creating a HASH of template entries, then defining each entry inside a single TEMPLATES.TPL file.

While there is some thought to keeping each template in a single file, so one edit won't screw up all the other templates, there is also a significant advantage to having one file, with all the various templates defined, then each variable fleshed out.

For ultimate compatibility, if a HASH entry is NULL, then the program would look for the file on disk.

This would work for user-defined profiles as well, since which TEMPLATES.TPL file is opened could be defined by the user profile.

This would also allow one more level of abstraction. Lets say you are developing a community site. If the template parser _only_ recognized a certain set of tags and HTML commands, then a user could create their own "configuration file" and change the look of the program to suit their own tastes or needs.

Templates are an exciting programming tool, and once you start to play with them, you start to wonder how you did with out them :)

Because the TEMPLATE.TPL file would essentially be a very large "static" or "constant" definition file, it could probably be set up as a '.pm' file, and pre-loaded into apache/mod_perl so there would only be ONE instance of the program code, and no I/O operation except on start up.

The mind keeps wandering... doesn't it??

Sorry for cross-posting this but it's rather urgent for me and may prove crucial for the general acceptance of the new templates:

I've put in a request to CIHost for them to install CGI::FastTemplate but who knows...

It says in the readme:

If you want to test out the module without installing it, you can add
the following to your code:

BEGIN
{
unshift(@INC, "/wherever/you/put/CGI-FastTemplate/");
}

use CGI::FastTemplate;


I assume that's the equivalent of 'installing locally'.
So, how does that translate for w3t?
Can I put FastTemplate.pm in my local cgi-bin and use:

unshift(@INC, "/www/amdragon/cgi-bin/");

and which files do I need to add this to?


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

Eileen,

I believe the only place you would need to add this would be in w3t.pm. But, you might not even need to do that if you put the module in the main wwwthreads directory. The scripts will look in the current directory for any modules they are trying to use.

Hey, that sounds great. I'll try it in the main wwwthreads directory first.

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

Yee-hah! We're in business! It looks for 'CGI/FastTemplate.pm'
so I made a /CGI subdir under my cgi-bin directory and put it in there (then I can use it for other stuff too)
Then in w3t.pm just above:

use CGI::FastTemplate();

I put:

BEGIN
{
# unshift(@INC, "/wherever/you/put/CGI-FastTemplate/");
unshift(@INC, "/www/amdragon/cgi-bin/");
}

Now let's get ready to rumble...

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

Have you done enough speed tests yet with the template version to know if the load is going to be increased substantially? It would be nice to know that it's going to be worth the trouble before we go ahead with rolling in our hacks.

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

Load really shouldn't be increased. The big load is starting up the scripts to begin with.

I'm sure performance will improve over time as the quirks are worked out though.

Perl is an excellent text processing/parsing language. That is what it was designed for. These sort of applications are right up it's alley.

I've done a few, but I'd like to get a little feedback from anyone using the dev version on their own server so I can see what they think. I may be overcautious about this but I'd hate to go full steam ahead on the templates and then find out they are creating server problems. So if anyone is using the dev version on their own server and has done any tests on load, post here or send me an email about your results.

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.