|Re: [higgins-dev] Scoping of configuration elements|
After thinking about this more deeply (and reviewing code), there's not enough information passed into the SettingHandler to do the sort of scoping that you're asking for. The SettingHandler has no idea about parent/child relationships. The ReferenceHandler only looks through the map that it's been given -- in the current MapHandler (and its descendents), this is the map that's currently being processed, not the map of all previously-seen settings.
I can think of a way for the ReferenceHandler to see the "global" map AND the current map -- by changing MapHandler to put the newly-created map into the global map before calling the enclosed SettingHandlers. However, this means that a reference would have to include a complete path from the top-level map to the particular setting that you want. (E.g., find the top-level "foo" setting, then look inside it for the "bar" setting, etc.) This may be OK, but it doesn't seem easily maintainable. (If I copy a setting, because it's mostly the same, but it's at a different level....)
I can't really think of a way to search "up" to the parent, then grandparent, etc., since we have a map, not a tree.
I understand that you want to avoid duplication, and I agree. Seems even harder, though, with the XRDS way of configuring ContextFactories. Each will be its own SEP, and there's no common place to put global info (as far as I know). Could put them in a different file, I guess -- use FileHandler to point to the file, open it, create a ConfigurationHandler (or whatever you like) to read the settings. Not pretty.
So, two things:
(1) Does the ReferenceHandler approach that I tried to explain above meet your needs? (Specify from top down.)
(2) Even if it does, is this capability going to be useless for the XRDS configuration anyway? (In which case, I wouldn't bother to implement it.)
In the Higgins configuration code, currently, we can only reference older siblings. We'd like to be able to retain this scoping ability so we don't have to redefine the same tables in every context. A "reference by id" mechanism might also suffice or be even cleaner where within the scope we desire it, we can say, "I want elements 12, 19, & 34". At any rate, we'd like something that allows us to not have to duplicate potentially large pieces of configuration everywhere it's wanted. Perhaps there's something like this already in there that I've missed.
higgins-dev mailing list
higgins-dev mailing list
Back to the top