Most Skuid data-manipulation Components already have this capability, which we internally refer to as “Data Conditions”, available via XML. When you define “Context” Conditions on Components that can be provided with context, you are in fact defining a special type of Data Condition to a Component, just a special type, but we support the addition of other Data Condition types as well — although currently only via XML. And as you have indicated, Pat, this can sometimes be simpler from a Model perspective because you can just have one Model but then only show certain records from that Model in different Components.

For example, say that you are on an Account detail page, and want to display different types of related Tasks in separate Tabs within the Account detail page, in different Tables, say “Completed Tasks” and “Open Tasks”. You could easily have 2 Models to perform this, but you could also just have a single Model to show all Tasks and then have a Data Condition on the Completed Tasks Table to just show records from the 1 Task Model where Status = “Completed” or IsClosed=true, and for the Open Tasks Table show where Status != “Completed” or IsClosed = false. 

However there are many reasons why we have not exposed this capability declaratively via the Page Composer — there are many common scenarios where the Data Conditions approach can result in somewhat confusing behaviors. Here are some examples:

• Search - performing a server-side search on one Table will affect all other Components associated with the same Model. This can be non-intuitive and confusing. Client-side search, however, will work well here.


• Limits on # of Records in a Model / Ordering / Load More - in the Tasks example above, if you limit to 10 records, and order by something like LastModifiedDate, you could very easily have 0 records in your Open Tasks table, even when there are open Tasks, simply because there are more recently-modified Completed Tasks. You’d have to retrieve a very high number of records just to pull in a few Open Tasks. Our “Load More” functionality also is Model-based, so just clicking Load More on the Open Tasks table will not necessarily pull in more Open Tasks, just more Tasks in the Task Model, which is non-intuitive. A separate Model approach is much better here.


• Filters - applying a Filter on one Table will affect all other Components associated with the same Model. Currently Skuid’s Filters are all executed server-side, so there’s no way to Filter just one Component without the change applying to all Components associated with the Model that was filtered on.

There are other caveats, but these are the big ones. If you can avoid these, though, Data Conditions can be a helpful tool. Because of these caveats, and because we only support it via XML, we only recommend this approach to customers on a case-by-case basis when it is necessary to achieve desired functionality. One common use case we recommend it for it is to add Conditions that are not supported by SOQL server-side, such as hiding some of the records from a table on an object’s Field History based on the OldValue or NewValue field.

In the future we may expose this declaratively, but we have held off on doing so for the reasons described above. 

---

^^^ bump for more votes ^^^

---

What’s the XML for this capability and is this have a timeline?

---

^^^ bump for more votes ^^^

This comes up quite often for me. The solution is the same each time.

1. Create a series of conditions on the model for each set of data I’d like to get on the page in different components.


2. Add the components to the page using this model.


3. Go into the XML to Cut and Paste the Conditions from the model into the appropriate components.

It would be great if I could simply create Conditions directly in the component. Essentially a secondary set of Conditions to further filter the initial model query.

Especially useful when a page has multiple record types for one particular object for a series of related records on a detail page.

---

When creating a condition for Search component in XML, is it possible to reference the value of a field from another model as the value parameter in the condition tag?

This is an excerpt from my xml... with the literal record Id in the value parameter, it works. What could I use to replace that literal with a variable that references a model.field called programCohort.Id?

---