I can get around the javascript error and get the page to load by changing my formula to something like this:

{{#$Model.MedicalExamReport\_PT.data.length}}"true"{{/$Model.MedicalExamReport\_PT.data.length}}

But then I get a page error from skuid:

If I put true without quotes, or 1 in there I get the same kind of error.

I tried to correct this by adding a second formula field like so:


With the formula:

{{#$Model.MedicalExamReport\_PT.data.length}}1{{/$Model.MedicalExamReport\_PT.data.length}} {{^$Model.MedicalExamReport\_PT.data.length}}0{{/$Model.MedicalExamReport\_PT.data.length}}

But in runtime, skuid gives me this page error:
Invalid syntax for field formula: {{#$Model.MedicalExamReport_PT.data.length}}1{{/$Model.MedicalExamReport_PT.data.length}}{{^$Model.MedicalExamReport_PT.data.length}}0{{/$Model.MedicalExamReport_PT.data.length}}. SyntaxError: Unexpected number

Why is a number field sad when it get’s a number?

Ok, I figured out that the ui-only field will fail with the javascript exception in the original post when the Model that it’s referencing comes after the field’s model in the builder’s model order. In my case, the PrenatalVitamins model was after the model that the ui-only formula field is on.

Trouble is, I can’t just switch the models, because the PrenatalVitamin’s model has FFAM conditions that reference the Interactions model (the model the formula field is on).

Any bright ideas on this one?

So, as a hacky work-around, I created two ui-only checkbox fields (not formulas). One default true, one default false. Then I conditionally render them based on whether the PrenatalVitamins model has rows.

Hey Matt -

Looks like you’ve been having a nice conversation with yourself so thought I would join in the fun

I logged the bug at https://community.skuid.com/t/uncaught-typeerror-cannot-read-property-displaytype-of-unde… 11 days ago (no response from Skuid yet) which is basically what you are running in to.  In the notes of that issue I describe what is occurring.  In my particular case, it’s a field but the same code path is hit when you go access data.length.

 In short, Skuid isn’t handling cross model formulas properly when formula in a model points to another model that comes after it.  There are lots of use cases to do this so I’m hopeful we’ll get some insight soon and it will be addressed.

Thanks for jumping in, Barry. Always great to have someone else in the same boat. Hopefully this one gets fixed up soon.

Matt~

Since you found a workaround, I’ll change this to an idea (the ability for a formula in a model to reference a model that comes after it). Might not be possible but I’ll let the devs chew on it as something the community would really like to see … 

Thanks!
Karen

Hi Karen -

In my opinion, the presence of a workaround shouldn’t determine whether this is an idea or a defect.  If every defect that has a workaround (which most do) were changed to ideas, there would be very few defects and priority of addressing wouldn’t be aligned properly to severity in the backlog.  

The issue Matt is having is either a defect or a limitation of Skuid.  If it’s a defect, it should be addressed and if it’s a limitation, it should be documented (so others can avoid) and considered an idea.

In my opinion, this is a defect for two reasons:

1) A formula should be able to access any model through global merge syntax regardless of model order
2) Any time there is an unexpected exception, there is a problem that should be addressed

A similar issue is posted at https://community.skuid.com/t/uncaught-typeerror-cannot-read-property-displaytype-of-unde….  That post is still awaiting an update from you.

Please let me know your thoughts.  Thanks!

Hear! Hear!