Matt, what is the id of the step you are navigating to, and are you sure that there is a valid Step with that Id?
To debug further, try putting “Show Message and Block UI” actions after each action you currently have, so that you can see which actions successfully completed and which ones did not.
I’m getting to the next step now. I didn’t change anything, so no sure what happened. Maybe just needed to reload the page.
Now the field editor isn’t showing up in step2. I added a template with merge syntax, and the right data is in Model2. But no field editor. I don’t have any render conditions or context conditions on it. It’s acting like there’s no data in the model, even though there is.
Any ideas?
Matt, it looks more like that the entire field editor is not getting rendered. If it were that a field editor had no data, youd at least see the save and cancel buttons (if you had them enabled).
I’m suspecting that you have a render condition on the field editor that is not working correctly.
Rob,
Thanks for the reply. I don’t have any render conditions on the field editor. I also don’t have the Save/Cancel buttons enabled. Let me try to enable them and see what I get… but without any render conditions, what else would prevent it from rendering besides a lack of data?
Yeah… the field editor is rendering, just has no data.
But the model has data.
Weird, right?
Does this mean that somehow the field editor is rendering before the model has been queried? But don’t field editors render again when a model is queried? Here’s the XML for the field editor… looks legit to me?
<basicfieldeditor showheader="true" showsavecancel="true" model="Inventory" buttonposition="" mode="edit" layout=""> <columns> <column width="100%"> <sections> <section title="Current Inventory" collapsible="no"> <fields> <field id="Inventory_Item__c" valuehalign="" type=""/> <field id="Lot_Number__c" valuehalign="" type=""/> <field id="Expiration_Date__c" valuehalign="" type=""/> <field id="Dosage__c" valuehalign="" type=""/> <field id="Quantity_Available__c" decimalplaces="" valuehalign="" type=""/> <field id="Primary_Storage__c" valuehalign="" type=""/> <field id="Additional_Storage__c" valuehalign="" type=""/> <field id="Control_Test_Complete__c" valuehalign="" type=""/> </fields> </section> </sections> </column> </columns> <conditions/> <renderconditions logictype="and"/> </basicfieldeditor>
Yes Matt, all components should listen to the models to which they are bound and show any changes made in those models. This is a strange issue. Would you mind giving us login rights to your org so we can take a look at what is going on?
Here is how:
1. Use this tutorial to give us login rights: http://help.skuidify.com/m/getting-started/l/182412-getting-help-how-to-grant-skuid-login-rights-to-….
2. Then send an email to support@skuidify.com with the following information:
- Your org Id
- The name of the page where the problem is happening
- The steps required to reproduce the problem.
We’ll see what’s going on…
Thanks for granting me login rights Matt. Here is what we found.
1. The template that you were using to show data was only showing the data from the record in step 1. You are using global merge syntax to populate the template. It was not really showing the data from the Inventory model you wanted to show in step 2.
(But that’s just a detail)
2. The action sequence that starts the popup needed to be rearranged. When you created a row in Reorder details model, the context for the entire popup became captive to the row you created. All components in the popup now carry a context condition to this row, which means that no inventory rows will match. What I did in your page was move the row creation action AFTER the popup page. Now the rows in the inventory field editor show.
There you go!
Rob, Thanks for the help. I’m not sure I understand how the global merge syntax I had in the template pointing to the Inventory model would be showing the data from “step1.” The only fields in step1 are on a different model. Maybe it’s just that i haven’t had any coffee yet this morning, but I’m feeling like a dunce. Can you explain that further? Is there something I can read or reference about context? I thought context was reset every time a new record was created… But apparently that’s not completely true? It’s definitely handy to have row creation before a pop-up constrain the context of the pop-up. Are there other similar situations? Thanks!
Not a dunce at all. Hopefully the coffee has been strong and effective. Here is some further commentary.
1. You included a template in step two with the aim of determining of data was present in the Model2 - where a new row had been created using data in Model1. However in that template you used global merge syntax to retrieve data from Model1, instead of retrieving the data directly from Model2. So though you had data populated in your template, it was not proving that any data was present in Model2.
2. Context. Documentation. Sigh… This is both a very complicated corner of Skuid, and one that is not well documented. We are continuing to work on its improvement, both functionally and in documentation. However, the only action in the action framework that hi-jacks context is the “create new row” action. Other actions will retain thier original context.
Sorry this is so sketchy…
Coffee was good, but apparently not helping much.
Does the set of merge syntax under Model2 in the following template not point to the data in Model2 (Inventory)?
So I’m equal parts shame faced, and vidicated… Here we go.
1. I totally missed the second part of your template - where you are sourcing data from the Inventory model. My Bad. But then why did data show there but not in the field editor?
2. Global merge syntax ( {{$Model.ModelName.data.0.FieldName}} ) is not going to be filtered by the row context in which it is found. It’s going to give you data from the array number you provide. In this case data.0 tells the syntax to get data from the first row of the model. So the Field Editor was looking at context (and not showing anything) while the global merge syntax was not filtering, and just getting the first row of data, regardless of whether it was the right on or not…
Pretty deep here. I may need another cup of coffee.
Nice. Thanks for the explanation, Rob!