James-
> You might want to reconsider the usecanonicalname setting. The hash element
> should exist if and only if it appears in the configuration file. It should
> be defined if and only if it has an argument in the configuration file.
>
> Thus, the following results:
>
> UseCanonicalName
> results in $conf->{usecanonicalname} == undef
>
> UseCanonicalName Off
> results in $conf->{usecanonicalname} == 0
>
> Then use existance in the hash array to test existance in the configuration
> file. You may have already been thinking along this line. If so, then I'm
> only clarifying a point...
You're exactly right - that's why I make a distinction between 0, 1, and
undef, so:
UseCanonicalName On # = 1
UseCanonicalName Off # = 0
#UseCanonicalName On # = undef (commented out)
That way, the logic in your script/module/whatever can set a default
value:
if ( ! defined($conf->{usecanonicalname}) ) {
# not specified, set default(s)
} elsif ( ! $conf->{usecanonicalname} ) {
# explicitly turned off
} else {
# explicitly turned on
}
This lets you default to any value you want (on or off). Does this help
clarify?
Regarding this:
> Perhaps
>
> 3. multi-level hash, i.e.
> $conf->{directory}->{'/'}->{sethandler}
>
> This is, afaik, more in-line with what the <Perl>...</Perl> sections do. I
> would suggest making it so the output of this module could easily be fed into
> the mod_perl configuration engine in the <Perl> sections. This gives us the
> ease of the second example with the programming simplicity of the first (i.e.,
> no new functions).
I actually like this alot. My question would be how to parse something
that didn't have one element, or that had multiple ones, for example I
can envision:
<Perl> </Perl>
<SomeContext "/a" "/b"> </SomeContext>
The first one exists, while the second one is (as far as I'm aware) only
theoretical. However, should they be solved as:
$conf->{perl}->{somesetting}
$conf->{somecontext}->{'/a'}->{'/b'}->{somesetting}
Input??? I just want to plan this out from the start so that as things
are added later the syntax and/or structures don't get unwieldy. I don't
want to change the "API" to such a module once it's out there.
Thanks again for the feedback.
-Nate
