best practice for using table data in action

I have been looking through the OutSystems best practices, specifically not using prep data in screen actions.  I can understand re-running an aggregate to get data that you then use in the screen action but I want to confirm what is the best practice suggestions for cases such as editing a record (I would assume you have to use the form record) or what if I have a table, populated by data from the prep, that has calculated fields where the user is putting in information and then I want to do something based on that information?  For example lets say I have a table of 100 records from the prep aggregate that I added a boolean calculated field called "pay".  Then in my screen action I want to go through the table record and any records that they user checked the "pay" field on a table, those get added to a local list and then I move to the payment screen.  Under the best practices it would not be good as I would need to pass that whole list from the client to the server however, the database doesn't have which records the user selected to pay.

I would send this to success at OutSystems but have had several bad experiences there and I am sure the first thing they would ask would be to send in my espace vs just answering the question. 

They would probably ask for the espace because all situations are different.

Best practices are called "best" and not "unique" because they are advisable, but sometimes you have to think outside the box. I would do re-querying for 1) avoid keeping too many data in memory; 2) ensure I'm not saving to DB the data some user tampered in the screen.

In your situation, sending 100 full records is not nice. I' say the best is to have a simple structure with (RecordId,IsPayed) and ideally you only send the ones with True.


Nuno Reis wrote:

They would probably ask for the espace because all situations are different.

Best practices are called "best" and not "unique" because they are advisable, but sometimes you have to think outside the box. I would do re-querying for 1) avoid keeping too many data in memory; 2) ensure I'm not saving to DB the data some user tampered in the screen.

In your situation, sending 100 full records is not nice. I' say the best is to have a simple structure with (RecordId,IsPayed) and ideally you only send the ones with True.


Nuno - I agree that all situations are unique but some questions like this are generalized enough that they should be able to just be answered - as you did!  So here is my question based on your answer.  Lets say I have an aggregate that is on bill line items.  So it has an id, a date, an amount and say 200 characters of text for charge description.  So lets say in the page I have local variable MyRecords list which is type list of record, and in the record section I just have BillId and IsPayed.  In the prep I run an aggregate to get the list of records and then do a list append all from the aggregate to MyRecords where I am just bringing over the BillId and set IsPayed to false.   On the page I would then have a table called MyTable pointing to MyRecords.  However here for all the other fields (amount and description) I would have to do gets on the BillId (something like getBillLineItem(MyTable.list.current.BillId).BillLineItem.Amount) to show the amount of the charge and the text.  Wouldn't that slow it down?  The reason I say this is that as soon as I call an action based on that data I would have to already have the user change "IsPayed" on MyRecords, not the original aggregate list correct?  I guess what I am asking is from your answer is this how you would implement it such that when you call the action to get which ones they have checked in the table, you pass it as small a list of data as possible.

You can do all the gets in preparation with a join. As long as you just use the two-attributes structure in the save action, the data transferred is minimal.

The alternative would be an ajax action on each click that saves into a temp table one by one and later the save action only moves between tables. But that is not ideal for those "Select All" button everyone loves to have, because you need to have the exact same list of entries and if the table in DB doesnt match the one read in preparation into the screen, it will be an issue.

Oh!  I think I get it now - you are using an input variable to the screen action and then just passing it that.  So I could use the prep aggregate for the table, and then when they hit the "pay" button pass the action the list with just those two variables being passed in.  I didn't think of doing it that way.