Couple quick updates:
-Autobinding: haven’t gotten a chance to debug this further yet, sorry. Will update when I do.
-@blueback09 There’s two solutions here. One is to manually create a field on the Parent thing with the contents of something, like you suggest. If the Something field is the main thing you’re using to retrieve Parents by, that’s probably the fastest. The other thing you can do is if you can narrow the set of Parents you might want to search down using fields stored on the Parent, you can then use an advanced filter to filter out Parents whose something doesn’t contain what you are looking for. This is only going to be efficient if you can shrink the number of Parents in the initial search to a number that’s not too big, since we can’t apply advanced filters without loading all of the data.
@johncottongim – it’s generally better to update a bunch of fields at once rather than lots of small updates in terms of write speed and on-screen performance. Re: page size, unless you have hundreds of workflows, visual elements generally contribute much more to total page size than actions / events, so I wouldn’t worry about optimizing that.
@florent.bocquelet – we’re not doing anything smart right now re: optimizing booleans… we’ll still do the search. That may change in the future, though, since that’s a common optimization in programming. Yes, putting it in a seperate conditional will get around this limitation for now.
@nathan.d.stevens – The main factor in long scripting times is total number of elements (and how complex / how many properties) elements have. Repeating groups are often a culprit in pushing up the total number of elements: a repeating group with 10 cells each containing two elements is faster than having 20 seperate elements, but it’s still much slower than 3 elements. You can control the timing via keeping things invisible; we generally don’t render elements until they become visible, so if you have most of your page in an invisible group, then show it a half-second after page load, you shouldn’t have the 5000 ms cost until that half-second delay, and in the interim you can display a lightweight message. (That said, the logic about when elements get rendered is a little complicated, so YMMV; test this empirically on your own app…)