Am 18.01.17 um 03:45 schrieb John from Decent Espresso:
from what I’m understanding, implementing a
anything-without-an-extension-is-adp would be a filter like this?
ns_register_adp GET /*^*.*
Is that right?
Can you confirm a file name of "test.situation.adp" would work with this filter?
It depends, what "work" means and in which order the entries are defined
(as discussed in the other thread).
In the following scenario, "/foo" is interpreted as ADP and "/foo.1" as
FILE (along with the more obvious cases.
=======================================================================
test ns_urlspace-5.3 {wild-card-filter with negative patterns} -setup {
ns_urlspace set -key 5.3 /*.* FILE
ns_urlspace set -key 5.3 /*.adp ADP
ns_urlspace set -key 5.3 /*.tcl TCL
ns_urlspace set -key 5.3 /*^*.* ADP
} -body {
foreach url {
/foo.adp /foo.tcl /foo.txt /foo
/foo.1.adp /foo.1.tcl /foo.1.txt /foo.1
} {
lappend _ [ns_urlspace get -key 5.3 $url]
}
set _
} -cleanup {
unset -nocomplain _
} -result {ADP TCL FILE ADP ADP TCL FILE FILE}
=======================================================================
However, when the first mapping is be changed from "/*.*" to "/*", this
will - in my current, uncommited implementation of negative patterns -
subsume the line with the negative pattern, and "/foo" will be mapped to
"FILE" as well (these subsumption interactions have to be looked into it
in detail, as indicated earlier).
Notice as well, that the NaviServer "filters" (registered via
"ns_register_filter") are an implementation completely independent of
the urlspace (used e.g. for "ns_register_proc", "ns_register_adp", ...).
Filters are collected in a linear list (not in a trie like in urlspace),
filters have a "continue" interface (e.g. should more filters be
executed?) and they use only simple tcl match on the method and url. So,
when the urlspace machinery is extended, this does not affect filters.
The urlspace trie is designed to scale and to work with large amounts of
url patterns (see as well the section "similar, but significantly
different" in [1]).
Wouldn't be a solution based on a default rule as suggested by Stephen,
where the name with out extension is mapped to the adp processor, which
checks for a default extension before retuning 404, an option for your
scenario? I've added the change for handling such a default extension to
bitbucket [2].
-g
[1] https://naviserver.sourceforge.io/n/naviserver/files/ns_register.html
[2]
https://bitbucket.org/naviserver/naviserver/commits/f563564dfc30f52a88483bda54f2c0887c17474f
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
