Search CGI is saying that <%term%> is unkown, and I can't find any other option.

Tried <%substring%> and that was unknown too.

Looking at your templates, and they try to pass <%term%> to the other search engines as well.

Robert.

More playing:

Replacing <%term%> with <%query%> works for the search_error.html, but gives unknown tags in the other templates... rather than holding empty values.

So, why then, is $term apparantly being passed in Search.cgi along with all the others? What's the difference? Why the difference between 2.0 and SQL versions??

Robert

More playing:

Replacing <%term%> with <%query%> works for the search_error.html, but gives unknown tags in the other templates... rather than holding empty values.

So, why then, is $term apparantly being passed in Search.cgi along with all the others? What's the difference? Why the difference between 2.0 and SQL versions??

Robert

Hi,

$term = $in->escape ($query);
$in{'term'} = $term; # ADD THIS

at line 79 of search.cgi and it should be fine. As for why the difference, it's because $in is no longer a global (again mod_perl restrictions) and it makes it more difficult to pass template tags.

Cheers,

Alex

I'm having this problem again.

In the templates... what should the <%...%> be term or query ??

The submit is 'query'

But, in links 2.0 that was used especially in the search error box to feed that term to outside search engines. How do that in SQL?

Hi,

<%query%> holds the unescaped search term, not recommended for putting in URL's. <%term%> holds the escaped search term useful for putting in URL's.

Cheers,

Alex

It's still not being passed right.

I realize there is a problem with global variables and mod_perl, and with OOP in general, but there has to be a way to set up a %template_values similar to the %globals, to make sure it's passed from the procedures to the template routines.

This would actually move more in the line of OOP, with a single object holding all the potential values for the templates, and it would be the job of the procedure to make sure the hash/array was properly populated before passing control.

This would also put all the potential template values in one place, and prevent the 'unknown tag' problem, since tags would be 'known' they just might be null.

It would also allow easier debugging, since a default value for each tag could be set in the definition, and if the value was/was_not over ridden it would help localize at what point the problem was occuring.

Can you explain a bit more what you would like to be able to do? Maybe a small code sample?

Cheers,

Alex

Right now, we pass the variables to the templates individually, or some in %globals.

Make %globals "globals" like paths and such, and a %template_codes hash that has all the available tags in it. Something I guess %tags should be, but doesn't seem to be.

It would be a list of all tag/value pairs, and would be passed to the templates. These values would be 'set' explicitly before any 'load template' call, or would default to the last value or no value -- never giving an 'unknown tag' error, but maybe returning 'null'

This would also allow someone to print this hash before a function call, to see what values are actually being passed.

An expanded "template" object would be a later development, holding all the possible template tags, as well as routines to operate on them and print/output the templates.

It seems that about 80% of all this is already there, but the actual modularizing it, and standardizing all the calls is still not 100%.