Alex,
This is still pretty minimal ie:
Code:
<%links%>
to:
<%loop links%>
<%include link.html%>
<%endloop%>
If people just have to replace a <%links%> tag with a new tag set, that is pretty easy!
Even complicated templates require only a minimal amount of work to do this.
I'm glad to see that all it would be is changing the main <%nnnnn%> to a set of loop tags.
The sacrifice of having to update your 8 or 9 templates that might use <%links%> or <%categories%> would then be far outweighed by the benefits!
People already have to change the search templates upgrading from 2.0 to 2.0 (term/query/etc). That is much more complicated overall.
Please, please don't get caught in the desire not to change something simple like <%links%> to <%loop links%><%include link.html%><%endloop%> if the trade off in performance is worth it. People will do that, and there is no reason to hold the development back.
The changes I suggested with the table prefix in front of the variables would be much more extensive, and would probably require a conversion program that presented the user with a list of new tags on the left, old tags on the right, and allowed them to change things if they needed to, then just did a search/replace on the template directories. It wouldn't be 100% perfect, but it would probably catch 99% of the tag changes, except those found in an <%if %> or <%loop %> clause. The search/replace program could compile a list of line #'s and files where it found those tags, so the user could change those they needed to, but all in all, even a major tag change wouldn't be impossible.
At some point, though, as the amount of linked data increases, the odds of two tables having the same field names increases. If the major tables used standard prefixes in front of the fields, then this would prevent crunching.
If you notice, w3t has updated their tables to use w3t_ in front of the table names, and a table prefix in front of each field in each table. This goes a long way to large, cooperative databases and programs. By adjusting the field names, you also require a one-time conversion process, but you get rid of large amounts of overhead in stripping/adding the prefix to the variables.
Again, now is a good time to start thinking about this!
Database use will only INCREASE over time, and the more you do to insulate Links' own tables, the better it will integrate into a larger site, and the more advantages it will have over other programs.
PUGDOGŪ Enterprises, Inc.
FAQ:
http://LinkSQL.com/FAQ Forum:
http://LinkSQL.com/forum
