Kirk,
"Just like magic" was my reply to Neil. ORDA is proving to offer more
efficiencies than the classic way.
The input and output forms, not so much the brain, are starting from scratch
with ORDA. The code in the example is in a text object sitting above an entity
listbox on the form. "Self" was changed to "Get Edited Text" so the listbox
changes after each keystroke, and ended up with this:
Case of
: (Form event code=On After Edit)
$text:=Get edited text
If ($text#"")
$obj:=New
object("$wordList";$text;"$fieldName";"Name";"$tableName";"Client")
$ents:=ORDA_WordQuery ($obj) // returns an entity
selection, match if field contains all @words@
If ($ents#Null)
ents:=$ents.r_Contracts
End if
End if
End case
// The ents entity selection is Contracts. $ents is a Client entity selection.
The text entry area expects a Client name.
ORDA handles the problems solved by SET AUTOMATIC RELATIONS in both the input
and output forms really well. It is also flexible in terms of writing generic
code. You are right about pointers not being useful when trying to point to
parts of an Entity.
Christian,
in your example:
$clients:=ds.Client.query("Name = :1";"@"+Self->+"@")
$contracts:=$clients.Contracts
is ".Contracts" meant to be the Table's name or is it meant to be the Link's
name?
Thanks, Keith - CDI
> On Dec 6, 2019, at 10:04 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> Keith,
> Neil is dead on in the case of RELATE MANY - you can access this directly
> from the entity via the name of the relation. But you are asking about
> RELATE MANY SELECTION where you have a selection of one-records and you
> want a selection of all the many-records.
>
> Your example works fine - though you don't need the step of converting to
> and from the array:
>
> $clients:=ds.Client.query("Name = :1";"@"+Self->+"@")
> $col:=$clients.distinct("PriKey")
> EntSel:=ds.Contract.query("to_Client IN :1";$col)
>
> By definition the PriKey should be distinct already but there's no downside
> to the command and it will also work for non-distinct values so it's a good
> habit to develop.
>
> I would shorten it to a single query line:
>
> $col:=ds.Client.query("Name = :1";"@"+Self->+"@") .distinct("PriKey")
> EntSel:=ds.Contract.query("to_Client IN :1";$col)
>
>
> This doesn't throw an error if the query is empty. And it's two lines of
> code to replace 7.
>
> I infer you are retro fitting this ORDA code into an existing form because
> of using Self and a process var for EntSel. My experience so far is this is
> the less optimal way to implement ORDA. First, classic 4D is probably doing
> just fine for this chore so carry on with what you've got. Introducing ORDA
> in cases like that usually don't work out great. Your example sort of makes
> this point - if you start thinking the way to solve an ORDA problem is to
> start converting back and forth between arrays you are probably missing
> something new you should be using.
>
> For UI stuff like this that means the object referenced by Self will
> ultimately be better handled if you begin using Form. I like to start from
> scratch when convert a form: make a new blank form. Copy in the most basic
> elements of it and learn to set it up using Form. You will know you're
> doing it right when you stop needing to rely on pointers (especially Self)
> and process variables to manage forms. I stress "rely on" here. Self is
> useful but if you are using ORDA it's the last resort, never the first.
> Process vars have a place but rarely - very rarely - for managing a modern
> 4D form. Learn to use Form instead.
>
> Once you have the basics working, (opening, closing, moving around,
> populating static or semi static objects) start adding in the other
> functionality. As you do that think about what you trying to accomplish -
> what is goal and purpose of the list, listbox, subform, etc. you are adding
> in. And how do you accomplish that with ORDA. This is important because
> whatever that task is accomplishing it with ORDA will nearly always be a
> completely different workflow from accomplishing it in classic 4D. If you
> simply paste in what you've been doing it's not going to really change
> anything. And if you don't want to really change anything what's the point
> of converting to ORDA?
>
> By putting this into a brand new form you eventually get to a point where
> you can compare your new approach to the old head to head. And this also
> makes it easier to swap out the new form for the old in your code.
>
> Hope this helps.
>
> On Thu, Dec 5, 2019 at 12:00 PM kculotta via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
>> Hello,
>>
>> RELATE MANY SELECTION is a convenient way to get a set of related many
>> records.
>> Is there a more succinct or efficient ORDA method than the following to do
>> the same thing?
>>
>> // get Contracts for a group of Clients
>> ARRAY TEXT($array;0)
>> C_COLLECTION($col)
>>
>> $clients:=ds.Client.query("Name = :1";"@"+Self->+"@") // get the clients
>> $col:=$clients.toCollection("PriKey") // make a Collection of Client
>> Primary Keys ("PriKey";"..Value..";"PriKey...)
>> COLLECTION TO ARRAY($col;$array;"PriKey") // make it an array of Primary
>> Keys
>> ARRAY TO COLLECTION($col;$array) // back to a Collection of Text
>> ("..Value..";"..Value..")
>> EntSel:=ds.Contract.query("to_Client IN :1";$col) // search in the
>> Collection
>>
>> Thanks - Keith CDI
>
> --
> Kirk Brooks
> San Francisco, CA
>
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
