Santy, Michael wrote: > This answers my question. I apologize for overlooking this in the > documentation. > > I was hoping that I could define one placeholder in the > customize.xxe_gui file that is replaced by all of the menus in the > configuration.xxe file, but it appears that you have to declare a > placeholder per configuration specific menu. The solution you suggest > solution will work great for my application. However, in the general > sense, it seems a little awkward to have a dependency from the > customize.xxe_gui to a particular configuration.
I agree. That's why menus defined in configurations must have *canonical* *names*. First menu must have no name at all, Second menu must be called "menu2", Third menu must be called "menu3", and so on. This is currently not enforced but just implied in the documentation. > I'll attempt to illustrate the problem. Assume a user has two > configurations installed: Config1 and Config2. Config1 wants to define > the menus "A" and "B". Config 2 wants to define the menus "C" and "D". > Right now, the xxe_gui file would have to declare all 4 placeholders in > order to accommodate either configuration. It would be nice if you > could define a "menuGroup" in the xxe_gui file that would act as a > placeholder for all configuration-specific menus defined in the current > configuration. When Config1 is loaded, the menuGroup is replaced by > menus "A" and "B". When Config2 is loaded, the menuGroup is replaced by > menus "C" and "C". Sorry, I don't really see how "menuGroup" would work. > I can workaround this particular problem in my application with the > approach you suggested because I'm only bundling one configuration with > XXE. I just think what I suggested above might be a more flexible > solution for configuration developers. Yes, we need to find a more flexible and more elegant mechanism to support multiple configuration-specific menus.
