According to Lachlan Andrew:
> Swapping the order of these solves the particular problem, but the 
> more fundamental problem is that any variable can (or should be able 
> to be) defined in terms of any other, and there is no ordering which 
> can allow that.  One possibility would be to go through and set each 
> variable *twice*, so that second time around, most variables should 
> have their right values.  Of course, chains of variables defined in 
> terms of each other would need more than two iterations...
> 
> Another option would be to merge  vars  with  config  so that the 
> literal string  ${PAGELIST}  would be added, and only evaluated when 
> the variable is finally expanded during output.

I think it's very important to keep a distinction between configuration
attributes and template variables.  They're two distinct things, and
for good reason.  I had thought a while ago, when adding to htsearch the
ability to reference any environment variable from a template, that it
might be a good idea also to be able to do so for any config attribute
as well.  Then it occurred to me that this could be a security risk,
as it would be too easy to reveal sensitive config information in a
result template, if you're not careful.

Right now, you can put an attribute name in allow_in_form to turn it into
a CGI parameter and related template variable.  It might make sense to
also add an allow_in_template attribute, to do just the config to template
relationship, without also the CGI parameter to config relationship,
so that you can securely expose some config attributes to the templates
without allowing a web user to override them.  However, I'd advise
against a wholesale merging of config attributes and template variables.

-- 
Gilles R. Detillieux              E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba  Winnipeg, MB  R3E 3J7  (Canada)


-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
_______________________________________________
ht://Dig Developer mailing list:
[EMAIL PROTECTED]
List information (subscribe/unsubscribe, etc.)
https://lists.sourceforge.net/lists/listinfo/htdig-dev

Reply via email to