Re: v17 Orda, Transactions, and ListBoxes with related many

[Kirk Brooks via 4D_Tech]

Hi Chris,

1) do table forms have any relevance in ORDA anymore?

Sure. Personally I am sticking with them for output forms in user mode, for
example. And I'm still including a bare bones input form as well. I
wouldn't use it for user-facing production forms.

I don’t want to mix ‘classic’ 4D in new projects, and so it seems that I
> should use project forms exclusively. What’s your take on that?
>
I haven't used MODIFY SELECTION in 10+ years. Forms I've made to allow
users to create selections have been dialogs with a listbox.

I am encapsulating my use of ORDA as I get familiar with it. What's that
mean? Within individual methods I don't mix them. As much as possible, and
so far it's been possible, I don't mix them in the context of an overall
task. So if I've got some update action to do which requires finding
records, evaluating and modifying them I'll do all that using ORDA or
classic.

There's a real temptation to use a classic QUERY 'cause I've been doing
that for a long time. But it's worthwhile to learn the ORDA commands for
doing the same thing.



> 2) Recording Editing with related MANY displayed in a ListBox.  ENTITY
> SELECTION-STYLE, not classic
> In a form, say, that displays an invoice, and the invoice detail is
> provided in a ListBox (Collection source), I am concerned about the
> situation where a user may delete lines from the Detail (ListBox) and then
> cancel the record edit (of the Invoice). It seems that editing the records
> (entities) displayed in the ListBox commits the changes as they take place.
>
Not unless you specifically call entity.save
().

The *entity.save( )* method saves the changes made to the entity in the
table related to its dataClass. You must call this method after creating or
modifying an entity if you want to save the changes made to it.


Does one control this through Transaction control (i.e. so that changes can
> be allowed, but not committed until OK’d)?
> If so, then how does one do that under ORDA, when one is using entity
> selections instead of ‘classic’?
>
The mechanics of this are what you are accustomed to.

ALL RECORDS
$selObj:=Create entity selection
START TRANSACTION
For each ($obj;$selObj) // read: for each $obj is $selObj...
If ($obj._ID%2=0)
$obj._ID:=$obj._ID-2
$obj.save()
End if
End for each
CANCEL TRANSACTION
In this instance each entity has _ID if it's even. Note the explicit save.
Since it's run in a transaction and the transaction is canceled the changes
aren't written to the datastore (records).

In the example you stated let's say you don't call .save() every time
there's a change - how do you do it? You want entity.touched()
.

The *entity.touched( )* method tests whether or not an entity attribute has
been modified since the entity was loaded into memory or saved.

If an attribute has been modified or calculated, the method returns true,
else it returns false. You can use this method to determine if you need to
save the entity.

ALL RECORDS
$selObj:=Create entity selection
START TRANSACTION

---  user stuff happens ---


For each ($obj;$selObj)
If ($obj.touched())
$obj.save()
End if
End for each

If($groovy)

VALIDATE TRANSACTION

Else
CANCEL TRANSACTION
End if



> When an INVOICE is to be edited:
>
> ds.Invoice.lock()
>
A pessimistic lock isn't necessary for the transaction to work using ORDA.
It's important in an existing database to avoid conflicts with 'classic'
processes because a pessimistic lock was the only type available before.

A note regarding user deletions of lines from a listbox. To be honest I
thought I understood how to do this but I just tested it and it's not
working. I filed a TAOW case on it asking for explanation so I'm going to
wait until I hear from them before saying anything about it.

Hope the rest helps.

-- 
Kirk Brooks
San Francisco, CA
===

*We go vote - they go home*
**
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
**

v17 Orda, Transactions, and ListBoxes with related many

[Chris Belanger via 4D_Tech]

Hi all,

I am really getting into ORDA-style programming with v17 and loving it.
Here are my questions:

1) do table forms have any relevance in ORDA anymore? I don’t want to mix 
‘classic’ 4D in new projects, and so it seems that I should use project forms 
exclusively. What’s your take on that?


2) Recording Editing with related MANY displayed in a ListBox.  ENTITY 
SELECTION-STYLE, not classic
In a form, say, that displays an invoice, and the invoice detail is provided in 
a ListBox (Collection source), I am concerned about the situation where a user 
may delete lines from the Detail (ListBox) and then cancel the record edit (of 
the Invoice). It seems that editing the records (entities) displayed in the 
ListBox commits the changes as they take place.
Does one control this through Transaction control (i.e. so that changes can be 
allowed, but not committed until OK’d)?
If so, then how does one do that under ORDA, when one is using entity 
selections instead of ‘classic’?

Maybe you can give some pseudo-code on how one would do this under ORDA.

Would it be:
When an INVOICE is to be edited:

ds.Invoice.lock()
START TRANSACTION (necessitating that this occurs in its own process so as not 
to interfere with other windows that might be in the process)

after user “ok’s” the record:
If  ds.Invoice.touched()
VALIDATE TRANSACTION[does this save the INVOICE and DETAIL records 
without having to do ds.Invoice.save() etc?]
else
CANCEL TRANSACTION
end if

if they CANCEL it:
CANCEL TRANSACTION

Thanks for your observations,

Chris
Innovative Solutions

**
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
**