Reg: Display of variable added in one Instance across other instances

too good jostien..u always help me out.. thanks a lot..

it will solve most of my problem as per now.. 

Thanks ya

Archu

hey Jostien,

one more doubt...please help me out. 

now that i can see the variables created in one instance across instance but now i want that the created variables should only be seen across few instances and not all created.

is there any restriction we can keep on it.

Please help

Regards,

Archu 

If you look at the arguments you can set on the SRL Entities Provider (either when used in a value holder or when you create the providere instance), you will see that you can filter based on subproject, ruleset and type, among other things. (These are the most useful ones when filtering)

If you place your group template instances in different subprojects, and configure the providers to only select variables from a certain sub project, that is one way to filter which variables are accessible.

Another way is to use a ruleset template as an intermediate in the group template. Note that this makes the variables local to the ruleset, not global, but depending on your needs, that might be an option. In that case, filter based on the ruleset names.

The third option is to filter based on type. For this to work, you actually have to create variables of different types in your group templates. The filter will make sure that only variables of the given type (or subtypes for class hierarchies) are available in the provider.

There is a fourth option, and that is to subclass the SRL Entitites Provider. This is slightly more technical, but entirely doable (I do it myself in several projects).

The trick is to subclass the com.blazesoft.template.repository.provider.NdPromSrlEntitiesProvider. Here, you can override for example the methods that return argument descriptors and parse arguments to the provider. This way you can add arguments that you can use to configure what kinds of entities are returned by the provider, for example based on regular expressions. If you do not need arguments, you can also simply override the getAllowedInstantiationValues method and filter the initial list from the original provider, before returning the result to the client (RMA).

HTH,

Jostein

Hey last option if u explain me with an example it would be very helpful.

Regards,

Archu

You can see the "Canadian states" provider example, which comes with Blaze Advisor for a general provider example. In that example you will see how to create argument descriptors so that you provider will have arguments, and also how to process arguments.

Just remember to extend the NdPromSrlEntitiesProvider instead of NdDefaultTemplateValueProvider or NdDefaultConstrainedListProvider.

Also note that when you override the NdPromSrlEntitiesProvider, make sure that you only extend the existing functionality, i.e. do not overwrite existing arguments. That means that when you override the getArgumentDescriptors-method, do something like this (code written from memory, so might not compile, and class/method names might be slightly wrong):

NdDesignProviderArg[] superArgs = super.getArgumentDescriptors(); // or base.get... if on .Net

NdDesignProviderArg[] myArgs = new NdDesignProviderArg[superArgs.length + 1]; // Add number of own args

System.arrayCopy(superArgs, 0, myArgs, 0, superArgs.length); // or .Net equivalent Array.Copy(...)

myArgs[lastIndex] = new NdDesignProviderSingleArg("Regular expression filter" );

myArgs[lastIndex].setMandatory(true);

return myArgs;

Likewise, in the setArgs, make sure you send the base arguments to the super class, and handle only your own arguments (easily done if you just select arguments to handle based on known names).

Then, you can override getAllowedInstantiationValues, for example like this:

public string[] getAllowedInstantiationValues(NdProviderContext context)

{

  string[] values = super/base.getAllowedInstantiationValues(context); // Original provider content

  if (regexFilterValue != null)

  {

     // regexFilterValue would be the variable that holds the filter expression taken as an argument

     Regex regex = ... // initialize regular expression instance

     List<string> newValues = new List<string>();

     for (string value in values)

     {

        if (regex.isMatch(value)) newValues.add(value);

     }

      return newValues.toArray();

  }

   return values;

}

I apologize for the mixture of .Net and Java -- work in both languages now, and the "last one written" has a tendency to sneak into code examples...

Anyway - those are the basic steps. Other than that it is only your imagination that stops you

Regards,

Jostein

will try it and let u know (http://blaze.i.lithium.com/i/smilies/16x16_smiley-happy.gif)

Thanks a lot

regards,

Archu

coding is too complex...through blaze nothing is possible?

well SRL type filteration works but  again the restriction comes on type of variable. 

if any other approach please let me know.

Anywayz.. thanks a lot.

regards,

What about subprojects for the different group template instances? Or putting the variables into rulesets? Are those also out of the question?

The subprojects-option is probably the one that matches your needs most closely, as it does not force you to convert to local variables...

Regards,

Jostein

not working ya..

thanks ya

Regards,

Archu

We have the hierarchy as given below,

Group template

   - Ruleset template

            - Rule template

            - Variable template

I have put the value holder (linked to variable template) in group template as entity placeholder.

We have defined one parameter in ruleset as "parm1" which is further being used to place the identity of variable defined through variable template.

This has resolved our problem of displaying variable (defind in variable template) across multiple instances of group template. But while compiling it is giving an error as "parm1 is not in scope". And as a restriction we can not even define parameter at Group template level.

could you please provide some input on this?

regards,

Archu