Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Scoping of configuration elements


I haven't looked at exactly how the ReferenceHandler works yet (just accepting the duplication while I get the first past finished).  From what you describe, it sounds like that approach would work.  I too worry about this being maintainable, especially if we support multiple scopes ... which "x" did you want?  Maybe we should just stick with global and local configuration.  Given that, what I'd do is name and include the global elements I wanted in a given local configuration.  Hmmmm, though I would want THOSE inclusions to apply to any descendants.  I need to get Duane to chime in on this because he implemented the "shared scopes" for the JavaScript configuration that precipitated the desire for this functionality.  I'd like to see what he ran into and why he made the implementation decisions he made.  Though I know, to a degree, it was only a "good enough" implementation.  However, I'd be happy with that kind of solution to maintain a level of simplicity.


>>> Greg Byrd <gbyrd@xxxxxxxx> 7/19/2007 3:37 PM >>>

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.)


Tom Doman wrote: 

In the old Realms configuration code that the Novell contributed CPs have been using, we had the ability to scope configuration elements to allow them to be referenced by any element within the same scope or any sub-scope of that element.  For example, in the JavaScript policy definitions, we could define a mapping table at the highest scope, and reference it throughout a number of context definitions, regardless of the depth of the sub-scope where the reference took place.

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 listhiggins-dev@eclipse.org  

Back to the top