Re: [higgins-dev] Scoping of configuration elements

["Tom Doman" <TDoman@xxxxxxxxxx>]

Greg,

I think it would be worth doing.  However, I'm almost done converting, rearranging, and adding new utility code to the higgins project all for the configuration code as it currently stands.  I'd like to get that all checked in before we do a breaking change.  I'm pretty close, barring a lot of other interruptions, I'm expecting to be all checked in by the end of the day today.

Tom

>>> Greg Byrd <gbyrd@xxxxxxxx> 7/24/2007 9:28 AM >>>
After further thought, I don't believe that my quick fix (adding the map object before the sub-settings are processed) will work.  The top-level map will not be passed in.  Only the map from the next level up.  Making this work will require passing in an additional argument, or using some global variable.  

My proposal would be to add an argument to pass the top-level map to all SettingHandlers.  This would be a breaking change, so I'd like some input as to whether it's worth doing. 

...Greg



Tom Doman wrote: 

Greg,

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.

Tom

  





Greg Byrd <gbyrd@xxxxxxxx> ( mailto: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.)

...Greg


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.

Thanks,
Tom


_______________________________________________
higgins-dev mailing listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev  
_______________________________________________
higgins-dev mailing listhiggins-dev@eclipse.orghttps://dev.eclipse.org/mailman/listinfo/higgins-dev