Apr 26, 2000, 10:42 PM
Veteran / Moderator (6956 posts)
Apr 26, 2000, 10:42 PM
Post #17 of 19
Views: 7116
First, the main point, is you miss the point of what I'm saying. There are many 3rd party scripts that are very good. Mailing list scripts are one group that Links only has rudimentary features for.
When I say the links mailer, I mean when the program is sending out mail, notifications, or newsletters, it's nice, convenient, and less bug prone to use the existing modules, routines and templates. Less "upkeep" is needed in the long haul. No ned to build your own send-mail routines (but it's _not_ a mailing list manager!)
I'm not sure what the "random text" feature does exactly, but I'm certain you can do the same thing _in_ links, using links calls, and have the feature/subroutine/mod be available in all templates, in all routines, in all areas of the program by including it in the %GLOBALS hash via HTML_Templates.pm or in the %LINKS hash (or other hash) via Links.pm
As I've said before, I hate reinventing the wheel, so use good scripts that do a job when available. Just _LOOK_ at Links first to see if it's already there! Some scripts are not worth adding into your site, if they make maintaining it down the road harder.
I'm using wwwthreads and I'm waiting for the upgrade of the Links user features so I can use them for both WWWThreads and Links.
I applaud Jerry for tackling the forum.cgi idea as almost an ultimate extension of what Links can be used for, but from my point of view it's an effort that is duplicating 3 or 4 parallel efforts already -- which are using the MySQL database -- and all that really is needed is to merge user bases. The Ratings/Review feature is what people have been waiting for, that's still in the wings.
'nuff said on this.
As for the development of Links.
If you look at Links SQL, it was designed "modular" and with OOP from the begining. It plays by about 90% of the rules of OOP, and 10% is still "perlish" short cut. (Alex may disagree, but it's not a criticism, just my view.)
Links is getting MORE modular and objectified, meaning the interfaces are going to be fairly stable, the code behind them will improve.
What this means is that the what I've been calling the "access scripts" in the public directory probably won't change much. They use "high" level calls to the links internals and DBI, so that interface is probably pretty stable. It may be "updated" but probably won't change much.
The search.pm _HOPEFULLY_ will change! It's the module that most people have had the most trouble with, _BUT_ the access to that module probably will stay the same, only all the "flags" will actually work.
DBSQL.pm promises to change, and incorporate more database flexibility, and utility. The calls themselves probably won't change, what they do behind the sceenes probably will, and there will probably be more calls, and/or options for them.
nph-build.cgi is _probably_ the file that will do the most changing. It changed significantly with the addition of page.cgi and subcategory.html.
Right now, the build routines are not objects with methods, they are actually "routines" that are performed.
In one of my musings a few months ago, I suggested a way (and then there were a few comments or alternatives) to define a site using a parameter file or hashes of hashes, or even define the structure via a table or two in the database. The site is then built from the data in this table and the "links" database. Such a design would handle virtually any combination of 'trees' and "links" database records storage. I also suggested a way of changing the current category storage to a B-tree (or n-tree) type of structure so each "category" is really a subcategory of something (either the root node, or another leaf) and all it knows is who it's parent is. Since each link knows what (sub)category it belongs to, and each (sub)category knows who it's parent is, you can build the site completely from that information. (If you added to that a third-dimention of "tree", each link would be a member of a category, and each catgory a 'child' of some other category which is eventually the 'root' node of a sub tree -- I know I'm not explaining this well, it's just a re-hash).
So, I guess what I'm trying to say at 4am is that there are going to be lots of 'code' changes. There are going to be lots of internal logic changes. There are going to be a lot of changes period. BUT most of the changes will hopefully go unnoticed because the calling method is still the same!
If we have a method 'get_categories' it may return the categories a link is in with the primary category in the first position, and any alternates following. If this is implemetned, then no matter how the logic of the categories may change, $db->get_category($ID) will always return the same data set.
This is where I see links moving to, whether it's there in this release or not (I doubt) since it's a major piece of work to get every sort of call into an object. But, _that_ is the only way to allow full version to version compatibility. (The down side, is there is a performance hit using indirection like this -- more than made up for on your first or second upgrade, but it's there.)
Expect the modules (*.pm) files to change greatly. HTML_Templates.pm hopefully will be largely spared, or will allow cut/paste upgrade. Expect the .cgi files in the admin area to change greatly. Their output will probably look and function the same, the internal process will probably be completely different. (Possibly the first step before being moved to a "build" object.)
Expect 'upgrade' type changes in the user .cgi programs (those in the public directory).
It's almost a guarantee that the nph-build.cgi is going to change. There are going to be propagated changes to the other files. Because nph-build.cgi still has embedded HTML in it, no upgrade is going to be painless until that need is removed.
You have to accept that minor tweaks are going to be subject to change in any next release. But, _THAT_ is what the templates help prevent! Unlike hard-coded HTML, your site's look will stay the same from version to version. Changes you make the actual build process you'll have to make in each upgrade. As more of links becomes "method calls" (ie: $db->something) these embedded changes may become fewer.
You'll be able to affect behavior by overriding the default behavior with a passed parameter. (This is how most object work.) You'll be able to re-write parts of the object you want to change -- but realize that that may not be carried through to the next release.
I've made very few changes to my jump.cgi since version 1.0 (the biggest change was adding in attachement support which I haven't yet tried out.) Jump.cgi is my most modified user-run program. All it's access calls have stayed the same. It does a bunch of different things depending on whether it's on a picture site or a URL based site, whether it's passed a jump-to-url-or-picture or a jump to a detailed page, etc. All that has stayed the same.
Anyway, I know what you mean about having to make changes from version to version. I went with Links because I have had to do it less than other programs. I've avoided programs that required too many changes each upgrade.
I don't want leading edge. I want planned growth, stability, maintainability, etc. I don't want to have to keep changing my software every 3 months because I've out grown it, or it's gotten "old".
If your site need leading - or bleeding - edge, my philosophies are probably not in line with your needs. But then, you probably should be taking development of Links beyond the release stage, and rewriting almost everything not in the Links:: subdirectory anyway.
I'm not trying to start a religious war. Just that I've spent a long time going over what the modules in links can do, and I have not found modules or cgi programs out there that will do any better, or that have a benefit to misery ratio high enough to make worth it to use.
Everyone has their own needs, and that's what great about Links. I'm running a postcards site, links site, and catalog/shopping site from links. Jerry has a FORUM working in it, and other people have made classified ads, personals, and other sorts of sites.
I needed better date handling routines for a project. CPAN has a whole bunch of them. Just 'use module' after you install it, and you've now got access to someone elses work -- often high quality -- and often just what you need to get you through.
Just as when you need to use template parsing or database access, 'use HTML_Templates' and 'use DBSQL' They are now part of your site building tools.