After a lot of trial and error

• Action 1: on on model queried, associate the parameters


• Action 2: on model changes, query the model

It was the only way to prevent a loop and it needed to be separate actions.

Hi @csilva glad you figured it out. Can you share more about what you’re doing and why you’re doing it this way?

Do you want the model to load for the first time with the Id from the parameter? Or are you updating it after the model has already queried?

If you want the model to load for the first time on (or after) page load with the Id from the parameter, you should just be able to use a model condition where “URL Parameter” is the value type. Then you can trigger the query by turning on “query on page load” or querying later via the action framework (e.g. action sequence triggered to run on page load, when a button is pushed, etc.)

If I’m understanding correctly, it sounds like you had a model action when the model was queried to filter and re-query the model - that would cause an infinite loop.

Hi Anna,

Consider the following set of actions that in any web application it would happen:

• A form


• An edit button


• A dialog to edit that form entry

The only caveat is what you are trying to edit does not belong to the form, therefore, you would pass parameters to the dialog to inform the object, id, etc.

What I’m trying to do with SKUID is the equivalent of that. I have a dialog that receives a set of parameters and from those it will lookup for the equivalent id given, load that data and present it for editing.

The first set of action is to set the parameters on a Ui-Only model upon querying. The second set is to reload the model upon model change receiving the Ui-Only model field as a parameter. This is the only way to prevent the infinite loop, otherwise, you are correct, it will happen. In my case on the dialog that is loading the model in question, the model has 2 actions. One will receive the parameter and associate with the id/key/search/etc upon model querying and the other, complete separate action set, will be triggered when the model is changed and that will re-query the model. This won’t create the infinite loop because the model won’t change again after those actions run.

This would be a piece of cake if it was javascript, therefore, SKUID javascript is quite limited and even if I was passing these via query-string, getting those on the javascript and loading the model, doesn’t work. Tried that path before. I believe the limitation is because the vdom.

Hi csilva,

Do you mind trying to describe what you’re trying to accomplish a bit more in general? I’m trying to tell if it’s about updating related information (I want to be able to click on the Account for an opportunity form and edit the Account’s details), edit a simple form, etc. It would make it a bit easier to answer, since all of this sounds like fairly core SKUID work that can be done without code.

Hi Matt,

This is a lot into business rules, but I will try to explain as best as I can without giving away business rules. For reference, consider that the logic is associated to a call center, just as an example, because this is not what where am I does, but the this process is similar enough.

Consider that you have a page that loads a bunch of information that a user like an agent will read. That information is related to client being filled in. Today in Salesforce and SKUID you can use Mustache to fill in the blanks, the caveat is that the fields for Mustache aren’t human friendly.

Example:

{{$Model.Client.data.0.first_name}}

For an user this is extremely hard to read, for a developer, not so much. Now if we had a place that would say that label = token, that would help, correct?

What I have built is a model that will hold the text that the agent will read and will give them a list of available fields to use within the text. So a manager, for example, could edit that text and add information to it.

Example:

Lorem Ipsum {{$Model.Client.data.0.first_name}} yada yada yada

If this was in a single page where the user would have a list and edit each one of them individually it would be simple. Create a page, add a model, have some edit buttons and voilà magic would occur. Unfortunately that doesn’t work because the manager, in order to write the texts correctly, needs to see how they would appear on the page. There is also a restriction to not show any extra information to add tokens that aren’t related to that page.

Considering the above, solution: create a page with the edit form and load it via modal. Attempting some re-use at least. At this point the edit form won’t know what to load to be edited, so I’m passing query strings to load that form. The query strings passed via dialog to the form are not accessible via javascript, which means loading the object via javascript is not possible.

The solution was to create a model that is Ui-Only model to receive the query parameters and a set of actions on the model to set those query parameters on the model and then load it.