11.3 Use Events to Refresh Parts of the Page

11.3 Use Events to Refresh Parts of the Page

  
Hi there,

this video is cut. It only have 3:31 minutes.
Also, at 0:45 on the video, it shows the SetIssuePriority Screen Action and there is an Screen Action called ListRemove. Where this last S.A, came from?

Best regards
 
Hi João,

the video has 7min. I assume you're having network issues, this the second video you have the same issue and I just tried it myself without any problem. 
As for the ListRemove it is something that we cover on the previous video. Make sure you take a look at it. 

Cheers

Thanks André.
It was a network issue.

Best regards
During these last two lessons, we learned to add a few steps including creating a Notify Widget, using the ListRemove function so that we could Ajax Submit on the High/Low buttons. If we had left these steps out, the screen would have refreshed itself and accomplished the same results.

So, is the importance of using Ajax Submit, Ajax Refresh have to do with performance of applications when we start thinking of real world applications using much larger databases. Is that what the instructor is referring to when he talks about performance?

I must also ask about the Ajax Refresh we used in the Issues Description web block under the ToggleDescription screen action. The instructor said we did not want to select the Issue Description web block for the Ajax Refresh. Instead, he went and enclosed the if widget description in a container and then selected that for the Ajax Refresh. I didn't understand why not just select the Issue Description web block when it appeared to work the same as I tried both.

Finally, going along with the video example in which Ajax Refresh was performed on the Description Container within the Issue Description web block, I was unsure how Service Studio knows that we are refreshing just the description in one row rather than all rows? So, I was thinking maybe the program will behave not the way we want by expanding all rows with descriptions that have more than 100 characters because now the SetDescription variable was set to True once the user clicks on "read more" for any description. When we click on "read more", we execute the ToggleDescription action but we are not passing on any information about the current row. It is simply an action that sets the SetDescription variable to True and then we do an Ajax Refresh on the Description Container.
Hi Sam,

The purpose of Ajax (which stands for asynchronous javascript and xml) is to be able to perform asynchronous request and to only refresh part of the screen. This means that the information sent back and forward between your browser and the server will be smaller than it would be if you would be using a normal Submit action. So instead of sending all the HTML code that composes the page you can send just the snippet representing that one object (a container, a input, a table,...). This can be very significant if you have pages with a lot of information.

The visible result of using ajax or submit is noticeable when you try to refresh the page. If your action is a submit action then the browser will prompt you if you want to re-submit the data back to the server as for the ajax submit request you won't get prompt for this. This is particularly relevant when you have forms to create or update data, because this re-submit means that the request will be executed again on server side which may lead to duplicate or inconsistent information, namely on the create scenario.

Finally regarding the objects inside TableRecords or ListRecords. What happens on the render stage is that the platform iterates the list bound in the source record list property of the widget. For each record in that list it creates a row in the TableRecords and the widgets are rendered with unique identifires. So if you have a named If in your table records (like myIf) this means that you will actually have as many If widgets as the rows you are rendering, each one with its unique id (e.g. myIf1, myIf2). The same happens to all named objects, like buttons or inputs.
When you bind these to screen actions, again the platform knows that that specific instance of the input or button is bound to that screen action and when that screen action is executed it has the context of the current row in the TableRecords and therefore you don't need to pass that context to the screen action via input parameters. So when you use AjaxRefresh with the If (myIf) on the screen action you are actually targeting the If widget instance (e.g myIf1) for that iteration of the record list or that row in the TableRecords.

I'm not sure I made myself clear on this last bit. If you have questions please post back...

Cheers
Andre...thank you...your answer is clear. I am starting Developer Bootcamp next week in Atlanta and I have been really trying to understand as much as I can from the videos. To be honest, even though Outsystems makes developing an application really fun...there is still quite a bit to remember and learn.
Hi,
These videos (10.1 to 10.3) are for just learning how to notify, etc etc or is the best practice for performance issues? To keep it simple we could just refresh the hole page. :)
Thanks
Hi,
These videos (10.1 to 10.3) are for just learning how to notify, etc etc or is the best practice for performance issues? To keep it simple we could just refresh the hole page. :)
Thanks
Hi Paula,

The main purpose of the video lessons is to teach how to use Ajax to refresh specific parts of the screen instead of refreshing the whole screen. It is up to the developer to make this decision but there are obvious impacts in terms of performance...

A side effect of using ajax is eleminating the common problem of form resubmit on F5.
Thanks for your reply André.
Hi,

Just a quick suggestion: you don't need to refresh the menu on the High Priority and Low Priority screens.

Joao