I answered a post in the other forum, about additions to the Verify routine, such that it would flag a link as "dead" and move it to a dead-links category, then move it back when it goes live. There are some neat features of this, and some good reasons to do it (such as the time cost in finding links that may be dead temporarily, or which a user may know has moved to a new URL):

http://www.gossamer-threads.com/...&part=1&vc=1

I'm seriously considering this as a mod, but really I would want it in the next release, as I plan to move my sites over as soon as it's available.

From a logic point of view, it seems almost trivial, the _major_ work is carrying it through the entire build/search routines (and page.cgi).

If this was built into the next level of logic, it would be much easier.

This begs the question: Could the next level of logic abstract the SQL queries into their own file/hash so they could be modified without searching through the code? Or, better yet, what about making them "flexible" so that they could be modified by the ability to add to the WHERE and other clauses on to the basic selects? I'm not sure which would be the over all best way, but extracting the SQL queries, would make it clearer how to modify them, and increasing the passed parameters would allow more modifications with less code changes (ie: customization/add-ons/plug-ins/built-in-searches).

http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/

Hi Robert,

All the SQL has been abstracted away now. You won't see any of it in any of the programs.

As for your suggestion, it would be fairly easy to do in the next version. Basically just add a third state to isValidated. As only links that have isValidated = Yes are printed and searched upon, others don't show up. You could say isValidated = Dead and it wouldn't be available until the link comes back up or you decide to delete this.

I'll look into any snags that might come up, but I think it should work without any issues.

Cheers,

Alex

--
Gossamer Threads Inc.

That would be great!

Being able to make a change such as isValidated = yes/no/dead would allow the possiblity to expand that system further as well.

I knew there had to be a relatively simple way (and I forgot about the SQL already being extracted --- as you can see from my picture, I have a lot on my mind <G>).


Going a step further:

What would be really cool, would be if isValidated was a "flag" field, where it was possible to set status indicators in a mask type situation. That way, you could have 8 status indicators on an 8 character field, and add indicators as necessary. Or, you could use alpha characters, and get 26 flags in a 26 character field (or 52 if it was case sensitive, or 36 with Letters + numbers).

For instance, a link could have the following status flags:

Validated = V
Pending = P
Edited = E
Dead = D

None of which is mutually exclusive. A Link could be Validated and Dead, or Pending, Dead and Edited for public view. These could be kept in Set_Flags = 'VPED'

Thus, if a link status you were checkging for was "IN Set_Flags" you'd know everything there was to know about a link.

This lends itself to a "plug-in" or module to allow status managment of links.

This would also get rid of a lot of the need for all the other fields people add for flags to do different (mostly trivial) things.

Using SUBSTR, LOCATE, and REPLACE to manage the field, or RLIKE.

While the management concept is a bit more tricky than using different fields, the fact it can eliminate a dozen or more (up to 62) fields makes it an interesting idea to consider.

I'm thinking more and more seriously about this, since some databases I've been working with have 15+ status fields, and it's a waste of database overhead, and actually becoming more of a problem managing them than if I had a couple of "status" hashes to do some masking with.



http://www.postcards.com
FAQ: http://www.postcards.com/FAQ/LinkSQL/