We actually had a pluggable matching API in the CAS4 branch that may be
useful to pull over/investigate.
On Tue, Aug 14, 2012 at 10:53 AM, Marvin Addison
wrote:
> > (Writing regular expressions for a long list of domains
> > becomes very unreadable very quickly.)
>
> Fully agree with that point.
> (Writing regular expressions for a long list of domains
> becomes very unreadable very quickly.)
Fully agree with that point. I'd say regular expressions generally
allow a lot of rope with which to hang oneself: anything non-trivial
is difficult to read and verification is a tedious manual proc
I fully understand. For simplicity of implementation we similarly didn't
add any new fields either or UI elements, we just used a longer prefix so
we could handle both "regex" and "domain" patterns. In practice we found
it was a little tricky to construct a good regex or ant pattern for a
domain
> 2) Additional algorithms and greater flexibility for registered service URL
> matching.
> Instead of ^(regex), we use various prefixes:
> regex:(regex)
> domain:domain1.com
Note that the requirement for prefixing a regex with a caret was
entirely for simplicity and backward compatibility.
Two of the changes that we've made might be useful to others in the CAS
community, so I'm putting them up on GitHub for review and consideration.
1) An enhanced ServiceThemeResolver that can select themes by host header
(while preserving existing theme-selection mechanisms). Also makes the code
