Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

Priority page mod is now posted

Quote Reply
Priority page mod is now posted
To anyone interested, I have gone ahead and organized instructions for the mod/hack to put together a Priority Links page:

http://run-down.com/mods/

Hopefully, I didn't overlook anything... Pugdog, feel free to index this thread in the FAQ. I suppose I could submit the mod to the Resource Center if people think it's of enough value?

I will work on the Featured Sites instructions next. The Image Ratings is more of a tweak of an existing mod for my site, but others might find the approach useful.

Dan
Quote Reply
Re: Priority page mod is now posted In reply to
I just posted the Featured Sites mod, but I figure it's of too little general appeal to bother with its own thread. You can find it at the same URL as above.

I fixed one itsy bitsy little typo in the Priority Page mod. I had written priority.shtml instead of the correct priority.html for the template instructions.

Dan
Quote Reply
Re: Priority page mod is now posted In reply to
Great work Dan!

Thanks.

------------------
James L. Murray
PaintballCity.com
The Yahoo of Paintball
www.paintballcity.com
AIM: Paintball City







Quote Reply
Re: Priority page mod is now posted In reply to
I added links to them in the mods area. You still might want to add them to the resource area.

------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/








Quote Reply
Re: Priority page mod is now posted In reply to
Thanks for the feedback/index. I'll go ahead and submit them for the Resource Center.

Dan
Quote Reply
Re: Priority page mod is now posted In reply to
Hello Dan,

I installed your featured site modification. How'd you get your site to show only one site when your featured page is brought up.

I want my page to randomly select a page for that day.

------------------
James L. Murray
PaintballCity.com
The Yahoo of Paintball
www.paintballcity.com
AIM: Paintball City







Quote Reply
Re: Priority page mod is now posted In reply to
I used Matt Wright's Random Text script, which just pulls a single line from a text file. That's why it was important that I be able to build the featured text file the way I did -- one link per line, set up in a manner that would produce HTML output when either randomly selected or the text file displayed in its entirety.

You can find the Random Text script at:

http://www.worldwidemart.com/scripts/

Dan
Quote Reply
Re: Priority page mod is now posted In reply to
Hello Dan,

Yeah I went to cgi-resources and found a bunch of random scripts to use there.

Question. I wanted to take this modification a bit further.

I wanted to be able to use cron and some sort of code to show one featured site per day, using cron of course to update the pages at 12:00 AM or something. This way the featured site was not a random thing, but a daily thing.

Any ideas on how to accomplish this?

------------------
James L. Murray
PaintballCity.com
The Yahoo of Paintball
www.paintballcity.com
AIM: Paintball City







Quote Reply
Re: Priority page mod is now posted In reply to
Hi James,

I'm thinking the easiest way to do that would be to build one of the Random Text programs into your nph-build.cgi featured routine. This could probably be done by requiring the program or just following its example and working it into the sub. I imagine use strict will complicate matters somewhat... But, if you have nph-build.cgi running via cron already, it seems like a waste to run another process to update one of its subs.

In which case, going the template route might be your best bet, with a tag for the daily link, as well as the option to show the full list of featured links.

Does that help?

Dan
Quote Reply
Re: Priority page mod is now posted In reply to
Hello Dan,

Yeah..that's what I was thinking. I was thinking of using this script:
www.onlinearts.net/showroom/dose/

However, I am not to sure what subs I need to add to nph-build.cgi for it to work correctly. Plus I still want to call it via SSI so that I can place the daily featured site on my homepage.

Do you think you can help? I would really appreciate it.

The way I see it is this: The way that scrpt runs is that you need to run the script dose.pl to show the daily text.

Therefore we would need to make it run when bilding the site and make a txt file on a daily basis. Then I could call that text file via ssi.

Maybe? You really seem to know what your doing, maybe, hopefully you can help me come up with something.

If you have AIM I would love to chat with you about it, my username is "Paintball City"

------------------
James L. Murray
PaintballCity.com
The Yahoo of Paintball
www.paintballcity.com
AIM: Paintball City









[This message has been edited by Ground Zero (edited April 23, 2000).]
Quote Reply
Re: Priority page mod is now posted In reply to
I hadn't looked at that script before. The problem with all of the 'daily' type scripts I've seen is that they aren't random. That's why I went the direction of going with a truly random setup, and making the output look a bit like a site of the day... I actually rather prefer it that way, as it brings up more sites throughout the day and the average person will never notice it's random on reload...

Any reason you are leaning toward the script you posted the link to instead of Matt's Random Text? It looks like both will have the same features and limitations, unless I'm overlooking something, and Random Text is super straight-forward.

Anyway, your idea of building something into cron is probably the best way of solving both problems. However, I have very little Perl programming skills (I would have been lost on these two mods if I didn't have examples to follow), and wouldn't be of much help beyond trial and error.

The way I worked on the Priority and Featured Mods was to put stuff into page.cgi and work on it dynamically. Basically just copy everything in (i.e. Random Text) that you want to work into the sub, and plug away at it until you get rid of the errors... Fortunately, the Priority Mod came through for me with no errors!

Dan

p.s. I avoid chat software like the plague. Wink
Quote Reply
Re: Priority page mod is now posted In reply to
Let me ask you guys -- _WHY_ would you use any 3rd party script when you have all the features necessary in Links, and can tag it to the standard builds, or via a separate cron job or random process?

Why would you install a different template parser/processer when you have an awesome one in Links?

I've converted almost all my other programs to Links Templates parser, and I'm converting more of them.

There have been script shells posted the past 3 weeks, plus the scripts that came with Links, that do virtually anything you need or want. All you have to do is put the appropriate calls in the middle of them.

Am I missing something?

My search script update to show the last keywords will let you insert _any_ data in any .cgi (or ssi) generated page. To do it for an HTML page, you just need to save the output to a file, rather than print it to the screen. You can make _ANY_ of the parts of Links -- or any parts you want -- available that way.

Plus, you don't have anything else to learn or maintain -- all the 'guts' are the same, only the .cgi wrapper is different.



------------------
POSTCARDS.COM -- Everything Postcards on the Internet www.postcards.com
LinkSQL FAQ: www.postcards.com/FAQ/LinkSQL/








Quote Reply
Re: Priority page mod is now posted In reply to
 
Quote:
Let me ask you guys -- _WHY_ would you use any 3rd party script when you have all the features necessary in Links
Speaking only for myself, because I don't have a clue what I'm talking about. Wink
Quote:
Am I missing something?
Nope, that would be me... I figured Links probably has everything built in to do what is desired, I just don't know where it is or how to use it.

Dan
Quote Reply
Re: Priority page mod is now posted In reply to
Figure out what you want to do, then look at what links does, and find the parts close enough to what you want to do -- and modify it.

If the script above just writes out a little html file -- what does links do? It writes out a whole site!

The code fragments I posted for the most recent searches cover most of the features you need. Just look for the code that writes out to a file, and change the 'print' to that output.

The next release (and future releases) promise some really great things. The more you build on the framework of Links, the less you'll have to remember to modify and keep track of later.

The postcards program is central to our site. It was based on a text program like Links 2.0. About 6 months ago, I modded it slightly to write parts of itself to an SQL database, and do look ups that way, but it was still running all the various template routines, print routines, and other routines of the original.

I spent about 5 hours changing over the parts of the program that handled the templates from the embedded system, to the Links system. I got about 500 lines of code down to 40 or so. I got rid of dozens of parameters I had to set -- using the ones from Links.pm and adding a couple extra.

I figure that was the hard part, and the 'send' card part (now that I got the recommend.cgi working) will take an hour, and will cut out another 200+ lines of code, plus it will use all the links routines.

My point -- most people are writing programs to work with their Links site. They are not writing standalone programs. So why expend the effort? Write code that uses the existing modules and routines of links, and makes calls to the MySQL database.

The two main templates are "search.cgi" or "jump.cgi" for getting things out of the database, and updating tables and logs, and the "add/modify.cgi" for inserting or updating database records. Between those two groups you can find most shells and routines you need. Looking at the HTML_Templates.pm file you can use the appropriate output rouines.

If you do things properly, the only files you'll have to modify on upgrades to Links are the HTML_Templates.pm file (with your added routines and globals) and the Links.pm file.

Now, I've made changes to build.cgi and such, but hopefully those will be less necessary in future releases.

The access programs -- search.cgi, jump.cgi, etc. which you customize may have to be upgraded to handle new features added to the upgraded links. But, they should continue to work with new versions until you upgrade them. Programs like recommend_it.cgi and reviews2.cgi shouldn't have to be modified either for the same reasons. They just tie in to the standard routines -- and should automatically access the upgrades (or be easily modifed to).

If I kept using my existing postcards program I would lose out on all the advanced features, or end up having to write poorer copies of them. By migrating it to MySQL and using DBSQL.pm and HTML_Templates.pm, as well as the Links.pm files, I automatically have access to the defaults that work, and to variables that you are familiar with -- script paths, output paths, etc.

If you add programs to the <%db_cgi_url%> directory, and and create paths for the programs output from the $LINKS{'build_root_path'}/my/new/path you've already eliminated a lot of errors, and created a much easier to maintain site!

If you tap into the Links SQL mailer, you know once it's set up, it will work. You don't have to worry about it.

Take the time to study the Links program, and what it does. Work within it's framework. There is nothing you can't do to your site by using already existing modules, or adding new ones -- not rewriting them!







Quote Reply
Re: Priority page mod is now posted In reply to
 
Quote:
The next release (and future releases) promise some really great things. The more you build on the framework of Links, the less you'll have to remember to modify and keep track of later.
I'm curious about one thing, but I imagine Alex has taken it into account: With Links SQL developing as rapidly as it is, is there much danger of significant code changes that migh affect incorporated mods? I was following the development of WWWThreads for awhile, and it seemed that I read three or four promises that this is "the last time" there will be an overhaul of the programming logic and code structure....
Quote:
Now, I've made changes to build.cgi and such, but hopefully those will be less necessary in future releases.
Seeing as how I've also made changes to nph-build.cgi, that caught my interest. What do you expect will be changing to allow that, and what will happen to mods already made to nph-build.cgi?

I agree it is nice to incorporate into Links SQL as much as possible, but I don't think you give the validity of a number of stand-alone scripts enough credit. For instance (and related to the discussion above), Links could be modified to pull a random featured link, but why bother? For my purposes, Random Text does exactly what I want with no modifications required.

You mentioned the Links SQL mailer, but there are many flexible mailing list scripts that are much easier to work with in several regards. The main advantage I see to the Links route is the user database, but that's currently of no use to me.

Basically what I'm saying is, to each his own. What Links SQL does, it does very well. But I don't see a need to make everything site-wide dependent on it. What if you are toying with one aspect of Links SQL in a production environment and while ironing out some bugs make the rest of the cgi-driven site inaccessible? This wouldn't be a problem with stand-alones.

Dan
Quote Reply
Re: Priority page mod is now posted In reply to
The difference is also what we are doing with our sites. Links _is_ my site, and is almost every aspect of it.

If Links is only a part or offering of your site, then you're probably running other scripts already, and Links itself is an add-on.

I would dare say that 4 out of 5 people running Links SQL have it as the central part of their site though.

Anything else they are doing to their site, is really being done to links.

That's the point of view I'm working from.



Quote Reply
Re: Priority page mod is now posted In reply to
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.



Quote Reply
Re: Priority page mod is now posted In reply to
 
Quote:
Basically what I'm saying is, to each his own. What Links SQL does, it does very well. But I don't see a need to make everything site-wide dependent on it. What if you are toying with one aspect of Links SQL in a production environment and while ironing out some bugs make the rest of the cgi-driven site inaccessible? This wouldn't be a problem with stand-alones.

First of all.... who would toy with any key part of thier site in a PRODUCTION environment!

I've changed a template and had my site disapper!

You need to develop on a test site, or non-public site. No changes to code should be made live until they work!

To reverse your logic though, what if you make a good change to your main site, now you have 3 unrelated other programs you have to try to make the same changes to.

Let's say each of those programs has a template parser. Now, you have to remember 4 different template tag sets, and make the changes to 4 different templates or template parsers...


(fixed the quote tags)

[This message has been edited by pugdog (edited April 27, 2000).]
Quote Reply
Re: Priority page mod is now posted In reply to
Wow, it's almost my bed time now that I'm done reading all that! Smile
Quote:
You need to develop on a test site, or non-public site. No changes to code should be made live until they work!
Probably true, although I rarely run into a problem, and if I do, it's never more than a couple of seconds till I revert back.
Quote:
To reverse your logic though, what if you make a good change to your main site, now you have 3 unrelated other programs you have to try to make the same changes to.

Let's say each of those programs has a template parser. Now, you have to remember 4 different template tag sets, and make the changes to 4 different templates or template parsers...
Well, for my site, pretty much all of the design is controlled by two SSI files, which are built into the Links pages. Changes I make in Links don't need to affect anything else, as Links is separate from other sections of my site.

I think the difference of opinion here (and it's hardly that, as I agree with your viewpoint for the most part) is largely in how much you want to incorporate all aspects of a site.

Dan