Assigning named foundsets

[david]

Any progress on the ability to assign named foundsets to forms (design time and solution model)? default, separate, and empty have been the only options for awhile now and my understanding was that the namedFoundSet property was put in place to be able to share named foundsets between various forms. Which would save us a LOT of cludgy workaround code that we currently have in place to manage a multitude of forms doing different workflows but all based on the same table. Some of the forms we want the foundsets to stay in sync (ie, a list and a form) while being completely separate from other forms.

Original explanation by Robert Ivens that we couldn't agree with more:

viewtopic.php?p=19143#p19143

[mboegem]

Hi David,

Progress on this feature was showed on ServoyWorld:
in the new v6.1, there's a possibility to use a relation as a 'named foundset'.
As you can now use literals in a relation (ie. don't need globals.one variable anymore to have a global relation on a certain table), you can see this as a find/search substitute.

Still not the real implementation we hoped for, but it's a start...

[david]

Didn't know that, cool. There needs to be a way of defining "named foundsets" and relations seems like a good way to me. No problem with that.

We're on RC3 (the latest as of now) and I don't see how relations are assigned to the namedFoundSet property. Am I missing something or is this yet to be implemented?

[mboegem]

Hi David,

this only works for relations using literals in the join.

relation.png (4.58 KiB) Viewed 14829 times

[david]

Created a few literal join relations. How can you assign them to the namedFoundSet property of a form? Solution model only?

[mboegem]

In my example this relation can be assigned on a form based on table 'orders' via the namedFoundset property of the form.

[david]

In my example this relation can be assigned on a form based on table 'orders' via the namedFoundset property of the form.

Ah k, finally got it. Also has to be a self relation. Which in hindsight makes sense.

I agree with your original assertion: this is not useful in its current iteration.

The way I see it working best is just being able to type in a name for namedFoundSet property (along with exposing getter/setter methods) and any forms that share this name and data source share the same foundset -- simple as that. Defining as a relation first seems a little hokey to me now and sets up unnecessary restrictions (even if all relations were implemented).

[mboegem]

even if all relations were implemented

Shouldn't be needed anyway.
You could generate relations on the fly and also assign this new relation to the form using the solutionModel.
With a little smart coding you could even pass in your search-criteria and let the method do the rest.

[david]

even if all relations were implemented

Shouldn't be needed anyway.
You could generate relations on the fly and also assign this new relation to the form using the solutionModel.
With a little smart coding you could even pass in your search-criteria and let the method do the rest.

I don't care about any of that for this feature. We just need to be able to separate foundsets out into chunks to control interaction. Doesn't matter what's in the foundset at this level. Do that down the chain.

[david]

I'd rather use scopes to define named foundsets than relations.