ORDA. The revolution continues.

Originally published at: https://events.4d.com/summit2020/session/orda/

Very fast paced, stimulating presentation of cutting edge ORDA!

I’ve been coding with ORDA for a while, but this keynote segment tell me that I still have a lot more to learn.

Good thing the material is digital this year, I can pause and rewind as much as I like…

Some comments on the sample code given towards the end:

Related blog post

https://blog.4d.com/more-sophisticated-orda-queries-with-formulas/

Point of interest for the code shown here

  • The placeholder :1 in the query string is pointing to a Formula, not a value. It is implicated that the formula evaluates as boolean.

  • The This in said formula would be a reference to the “current” entity during query execution.

  • The nature of the studentAverage expression is not very clear, but I think it is a project method. Normally you would think that the comparison is against the average grade of all students, but that would be a constant, so no need for an expression, no need to pass This as a parameter. So it seems that the method is designed to iterate all grades for this entity, i.e. the average grade of all the subjects that this student is has been graded for (because each student takes a different set of classes). Grades could be A to F, but the reference to an average implies that it is numerical. Perhaps something like

$0:=OB Values(This.grades).average())

https://blog.4d.com/objects-corner-easy-sharing-other-good-news/

  • On top of that, there is yet another query criteria, the country of origin, which is suggested to be “England” as an example. It seems counter-intuitive to look for an English student who is doing better in English compared to all other subjects…I am probably over thinking it, I know…

Point of interest for the code shown here

  • Placeholders (:1, :2) are no longer used, instead, the parameters are named.

  • Why use named parameters? The speaker suggests “user interface”. At first, I couldn’t quite grasp the significance; the same seems possible with the old syntax. In fact, using specific attribute names seem counter to generic coding. I may be wrong, but I think the point here is that the new syntax makes it easier to design the query code independent of the API or UI that invokes the query. The matching name of properties is what links the modules together. In classic 4D we tend to think of generic code as anonymous and abstract, where it is considered good to remove as much names (tables, variables, form objects) from code as possible, but in object-based programming, it seems to be the opposite. Names (attributes, properties, methods) are absolute anchors in object-based code, so having specific names “hard-coded” actually contributes to making the code more modular and generic (in the sense that it is agnostic to its surroundings).

Related blog post

https://blog.4d.com/add-values-to-your-generic-orda-queries/
https://blog.4d.com/placeholders-for-attribute-paths-in-orda-queries/


That said, I fully agree with Kirk, what I like the most about ORDA is that it’s fun to code.

Hi Keisuke,

Yes, studentAverage is a project method looping on all the student’s grades (which are numeric) and computing the average. This method may also apply coefficients, for example, coming from the student’s school (This.school.coefficients can be an object containing coefficients for each subject).

I agree, the example with // $country = “England”
could be changed to something more logical.

Thank you for your feedbacK.