On 10/23/07, Vasiljevic Zoran <[EMAIL PROTECTED]> wrote:
>
> On 23.10.2007, at 19:25, Stephen Deasey wrote:
>
> > Two interesting failing test cases:
> >
> > test cfg-5.4 {defaults propagate to global store} -body {
> > ns_getconfig section cfg-5.4 foo
> > ns_getconfig section
> > } -match glob -result {*cfg-5.4*}
> >
> > ---- Result was:
> > cfg-4.1 cfg-3.2 cfg-4.2 cfg-3.1
> > ---- Result should have been (glob matching):
> > *cfg-5.4*
> > ==== cfg-5.4 FAILED
> >
>
> This can happen if "cfg-5.4" was never declared.
> The "ns_getconfig section cfg-5.4 foo" will NOT
> trigger error if the section/key is missing. It
> will just return empty string (as ns_config does).
> Correspondingly, the "ns_getconfig section" will
> return just those keys that have been ns_setconfig'ed
> so far.
But one of the things we want to support is introspection, right?
foreach section [ns_getconfig] {
foreach {k v} [ns_getconfig $section] {
...
}
}
The only way to make it work atm is to pre-declare all config values:
# mylib.tcl
ns_setconfig section enabled true
...
proc foo {} {
if {[ns_getconfig section enabled]} {
...
}
}
...
Pre-declaring is a new restriction. Is this the plan?
I could also imagine having a hybrid system, where you *could*
pre-declare, but you could also have ad-hoc calls. Both have their
benefits:
- Config which is only referenced once, and rarely if ever needs to be
changed, is ideally handled with inline calls. Everything is in one
place.
- Config which cannot be guessed, e.g. a host name, or which is
accessed from multiple pieces of code, would benefit from a
declaration. This would allow the default to be written once and make
options for configuring code more obvious.
A system of pre-declaring might have benefits for C-code especially.
Or..?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
