No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Using Canvas.provideRuleScope property

    Hello Isomorphic
    I have a filter form that has selected values for context that I would like to be able to access in a window modal DynamicForm.
    The search form does not fall into the default ruleScope and it seems that I can add this form using the Canvas.provideRuleScope property but cannot figure out how to use it and cannot find any forum posts or any other mention of its usage other than this :

    Here is the simlified XML component definition I have:
    [HTML]<SearchForm ID="SrchFrm123"><fields><field name="bling"/></fields><SearchForm>
    <Window><DynamicForm ID="CrudFrm678"><fields><field name="blah">...</fields></DynamicForm></Window>[/HTML]

    I would like to add a dynamc optionCriteria to field "blah" that fetches the value of field "bling" using the optionCriteria like this:
    [HTML]<field name="blah" title="My Field" type="select" autoFetchData="false" editorType="ComboBoxItem" displayField="blah_name" valueField="id" optionDataSource="S9d7c4fd038_ds" ><optionCriteria><fieldName>"bling"</fieldName><operator>"equals"</operator><valuePath>"SrchFrm123.values.bling"</valuePath></optionCriteria>[/HTML]

    Is it possible to use provideRuleScope attribute to make the SrchFrm123 form accessible from the CrudFrm678 DynamicForm?

    Help would be very much appreciated.
    Last edited by; 15 Sep 2020, 15:29.

    Any DynamicForm will provide it's values to the ruleScope under it's ID, so it's already in the ruleScope in pretty much the format you're expecting, however, you are quoting the values for valuePath etc which is incorrect.


      Thanks for the reply - my bad - I transcribed the example with quotes but in the actual implementation it does not have quotes.
      The reason I am focussed on the provideRuleScope (or provideRuleContext if that is better) property is because if I change the "valuePath" attribute value to the same DynamicForm the field containing the dynamic optionCriteria is, then it correctly retrieves a value and passes it in the "criteria" part of the request to the server as expected.

      Because this works, I am operating under the possibly incorrect assumption that the "SrchFrm123" form is not within the scope of the "CrudFrm678" form.

      Reading the spec on ruleScope my understanding is that if no ID field is set then it uses the parentCanvas chain to determine the accessibility of other data which if I have understood it correctly means the <Window> element containing the "SrchFrm123" form is not within the scope of the "CrudFrm678" form parentCanvas chain.

      I have tried setting "ruleScope" attribute on the "CrudFrm678" to:
      ... but that has not made any difference.

      NOTE: I have verified before the <Window> element is instantiated and the datasource call is made for the "blah" field that in the browser console running "SrchFrm123.values.bling" returns the expected value that should be passed in the criteria request param construct for the "blah" field datasource request.

      This is using "v12.1p_2020-06-06/Pro"
      Last edited by; 17 Sep 2020, 04:56.


        Did you notice the API getRuleContext()? You don't have to speculate about whether data is present or not, you can just look. The echoFull() method is a good way to get a quick JSON dump.

        It's true that if you have two different top-level hierarchies, like a Window that isn't contained within the same top-level parent as other components, those are separate ruleScopes. If you are having trouble unifying them via the canvas.ruleScope property, please show us the actual code, as a minimal, ready-to-run test case, and we can take a look and either correct your usage or fix a bug if one is revealed.


          Thanks for the advice - it has helped me to get clarity on rule scope and subsequent experiments leave me wondering how to solve the problem.

          I am using a popup window as the record edit mechanism and therefore have declared the Window element as a standalone object.

          This is the structure where the "MainCanvas" element is intended to occupy the full screen and the edit poup shows on a doubleclick of the record in the ListGrid:
          <VLayout ID="MainCanvas" height="100%" width="100%">
          <HLayout ID="ContextObjects">
          <SearchForm ID="SrchFrm123"><fields><field name="myFilterField"/></fields><SearchForm>
          <HLayout ID="ActionButtons">...></HLayout>
          <ListGrid dataSource="myListGridDs"><...></ListGrid>
          <Window ID="CrudWindow">
          <DynamicForm ID="CrudFrm678">
          <field name="myEditField" optionDatasource="myEditField_ds">

          In this format, the "SrchFrm123" object is not in the rule scope of the "CrudFrm678" object - it ruleScope is "CrudWindow" (and all data contributing elements within the "CrudWindow").
          The rule scope for "SrchFrm123" is "MainCanvas".

          If I include the "CrudWindow" object as a member of the "ContextObjects" then "SrchFrm123" object is in scope as its ruleScope is "MainCanvas" and the optionCriteria works as expected.

          However, if I include it as a member of any of the elements inside the "ContextObjects" then it does not popup as a floating window but instead occupies the space within the element it is included which is not the desired behavior.

          I have tried setting the "CrudWindow" object as ruleScope="MainCanvas" - this drops the visibility of the the "CrudWindow" data objects from its rule scope but only provides access to the ListGrid element data objects in the rule scope.
          Setting "CrudWindow" object as ruleScope="SrchFrm123" drops all data object visibility.

          Can you provide guidance on how to configure the <Window> element so we can use it as a floating popup but have rule scope with access to its standard data bojects contained within the "CrudWindow" but also add "SrchFrm123" object into the rule scope?


            Yes, as we previously covered, setting ruleScope on the Window is the way to solve this problem.

            If this doesn’t seem to be working, then as previously indicated, we need a minimal, ready-to-run test case before we can take a look.

            We already have a lot of automated test verifying that this feature works in general, so some small detail is likely different or wrong, so anything other than minimal, ready-to-run code is useless.