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

After talking to Daniel, I realize I should clear up that I'm talking about the setting handler process while we're processing the configuration on startup, not at runtime.


>>> "Tom Doman" <TDoman@xxxxxxxxxx> 7/16/2007 10:57 AM >>>
By "older siblings", I meant, in the recursive process, I can't refer to parents, grandparents, etc., only sibling elements that came before the current element.  This works out a little in that if all the younger siblings refer to the older sibling, I get some benefit.  I've attached an example configuration for reference.

It seems like reference by name might suffice (as long as they don't have to be siblings) but I'll let Duane chime in also on what he'd like to see.


>>> Greg Byrd <gbyrd@xxxxxxxx> 7/16/2007 10:05 AM >>>
There is a reference type that lets you refer to a previously-encountered element ("setting") by name.  I think that's what you meant by "older siblings"?  You could have a top-level setting that contains the table that you want, and refer to it by name.  Would you prefer some sort of path-oriented naming, like "Setting1/SubSetting3/SubSubSetting2"?  (I think that's fairly easy to add.) Is reference by name OK, or are your really hankering for positional references?


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