When everything is finally abstracted out, that line of code will be part of an HTML file, most likely.
First, I don't use the category groupings, because searches should be by relevancy, not categories -- where the most relevant category or link could be the last one presented. This was the first thing I removed from Links 2, and the first thing I worked around in Links SQL.
Second, adding another template for what is a single line of code, may help in data abstraction, but it would incur a performance hit. Since the "formatting" is actually part of what "search.cgi" is doing, ie: presenting the "found" links by category, editing the line of HTML in that file is _not_ unreasonable, or bad form.
Yes, it would be nicer to have all this embedded html in one place, and it eventually will be, but this is _not_ a "links results" formatting or template, which is what I couldn't understand.
There is no way to embed this in the current logic, since each "block" has to be a fully encapsulated block.
You would need to _alternate_ the sub-category name template with the link.html template.
You could do this yourself, actually, if it's that important, but you would incurr a performance hit for that one line that is probably not worth it in the larger scheme of things.
90% of what would need to be done could be set with a <FONT> and a prefix/postfix tag set, where they are set as global configuration options. Beyond that, anything would really be "custom" programming, and editing a single line of HTML in the .cgi file is _still_ the most "cost effective" solution.
This is why I had no idea what you were referring ot.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
First, I don't use the category groupings, because searches should be by relevancy, not categories -- where the most relevant category or link could be the last one presented. This was the first thing I removed from Links 2, and the first thing I worked around in Links SQL.
Second, adding another template for what is a single line of code, may help in data abstraction, but it would incur a performance hit. Since the "formatting" is actually part of what "search.cgi" is doing, ie: presenting the "found" links by category, editing the line of HTML in that file is _not_ unreasonable, or bad form.
Yes, it would be nicer to have all this embedded html in one place, and it eventually will be, but this is _not_ a "links results" formatting or template, which is what I couldn't understand.
There is no way to embed this in the current logic, since each "block" has to be a fully encapsulated block.
You would need to _alternate_ the sub-category name template with the link.html template.
You could do this yourself, actually, if it's that important, but you would incurr a performance hit for that one line that is probably not worth it in the larger scheme of things.
90% of what would need to be done could be set with a <FONT> and a prefix/postfix tag set, where they are set as global configuration options. Beyond that, anything would really be "custom" programming, and editing a single line of HTML in the .cgi file is _still_ the most "cost effective" solution.
This is why I had no idea what you were referring ot.
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
