3 Replies Latest reply on Nov 20, 2012 3:31 PM by JasonBatzlaff

    First event after Configurator session Initialization ?

    Akhil Agarwal

      We are launching Configurator thru a third party application. During the initialization we are passing ~10 Custom parameters.
      All these 10 parameters are being mapped into Configurator into either a Text Feature, Option etc (we are doing this thru a extension)

      Now we want another extension which should trigger as soon as all these ~10 parameters are set (in configurator).
      Which event would be ideal in such a case?
        • 1. Re: First event after Configurator session Initialization ?
          Is it not feasible to simply include the code that would be the second Extension at the end of the method that sets your custom parameter values? Or include the "second Extension" code in a second method that gets called at the end of the first?

          • 2. Re: First event after Configurator session Initialization ?
            Akhil Agarwal
            Thanks Eogan and Ravindra for the reply.

            The issue was that there were 10-15 external parameters which we wanted to pass into configurator (and we didnt want to hard code them). Hence we had created a generic code due to which we ended up creating corresponding number of 10-15 binding/calls (one for each parameter).
            Now what we wanted was that after all these 10-15 parameters are set into configurator , another extension should fire.
            Due to this scenario we are unable to include the code of the second extension in the first one (as the first one is being called up 15 times (to set the parameters in Configurator)

            As a work around we are planning to re write the java extension to set the 15 parameters in a single shot (so that we can include the second java code beneath).

            Any other workaround suggested?
            • 3. Re: First event after Configurator session Initialization ?
              I have done similar things with a "defaulting" cx. Each model could default any number of options. The options were not hardcoded and each model had different options to default. The way we handled this was through properties. The input to the CX was a model node (in our case, the top model node). Within the CX, we looked for very specific properties on this node (e.g. DEFAULT_PATH_01, DEFAULT_PATH_02). The value of the property was a "dot-delimited" path to the node to be selected by the CX.

              The CX was flexible to look for any property beginning with "DEFAULT_PATH_%' and processed the paths in the order of the index (e.g. 01 then 02 then 03 and so on). In this manner, we had a single CX that fired at the beginning of the configuration that would set various values immediately when the model was opened. The defaults were also applied in a very specific order (since this usually matters in the case that one option must be selected before a second option is available). Using the "Dot-delimited" path allowed us ultimate flexibility on which nodes of the model could be selected. We could point the path to any node within the model.

              if you were to use similar logic, you would not have the same difficulty that you mention in your prior post. My initial opinion is it might be better to re-write the original extension so that you can easily add the addition code at the conclusion.