Possible bug - Record list is empty.

Possible bug - Record list is empty.

  
How can a record list, contain a record, yet the the record list properities suggest that the list is empty?

Empty=true would mean that there is no records in the record list what so ever.



Since there is 1 record in the record list, (you could also see this from the attached image above), the correct result should be
"Empty" =  "false" and
"Length" = "1".

Hello, Robert!

You forgot to attach the "attached image above". Please do so so we can help you!

Thank you,
Pedro Magalhães
Robert,

Would it be possible that the RL is set to the local variable (List) and then the current record is set with values from inputs?

So some more information what you do before you come to this List with value.

Kind regards,
Evert
Hi Guys,

It's an old issue with "debug viewer".

Regards,
Rafael Pereira
Rafael,

Would that mean you have experienced this issue before? how did you correct the problem?

In debug mode the record list contains a record, but in production nothing shows up! 

See eSpace with bug attached http://dl.dropbox.com/u/678582/Outsystems/eSpace-withRLBug.oml
Hi Robert,

Actually, what Rafael was mentioning is that there is an issue in debug mode that in record lists, the variables are not always displayed correctly, because of some perfomance optimizations... However, they should not reflect on the actual application flow/result.

What this means is that, while it displays length 0, what is the result there if you access the List.Length property directly in your action flow? It should not be zero, if there's at least one record.

Are you able to test it?

Let me know if the problem still shows up. If it does, I'd send it directly to support, for them to direct it to our maintenance team.

Regards,

Paulo Tavares

Paulo

This bug does, does in fact, affect the business logic, as you can see from the eSpace application the RecordList has been assigned a value, and that record is displayed in debug mode, it is the correct value displayed. However in production, nothing shows up the record list is empty but in fact there is a record in the list.

Issue has been submitted to outsystems support.
Hi Guys,

Paulo: Correct, I was talking about the debug issue. 
Robert: 

My guess: The second flow doesnt work because you are missing the ListAppend.
Service Studio doesnt complain about your assign but you are assigning values to an Empty record list (BalanceList output parameter).

Try the solution that i've mentioned and give us feedback... 

1) Assign the values to an Record variable
2) Append the Record variable to your RecordList output paramater.




Regards,
Rafael Pereira
Rafael, 
 

http://dl.dropbox.com/u/678582/Outsystems/TestAnimal.oml

A simple test was created , and the test fails!
 
You must always use ListAppend when you add a record to a recordlist, even if you want to assign 1 single record to current record on the list. You still need to use ListAppend.

Strangely enough the test also shows that If the variable is a record, (and not a record list) you still can not assign the record with a value and output the assign record value. How else are you suppose to do it then?
 
Hi Robert,

First, let me express how I feel after successfully help a "316 posts community member":



I agree: It's a weird behavior but Service Studio cannot "evaluate" everything on design time and recordLists are different from other types of variables... 

Regards,
Rafael Pereira


Thanks for the fireworks Rafael :)

Its just not recordlist, you can not assign a value to a record and try to output the record onto the screen.

Debug mode shows that the correct value has been assigned but on the screen it does not show the value.

 
If that is not strange enough, after further testing, it shows that when you use an expression to display either a record value or recordlist value the correct value are displayed on the screen!

Hi Robert,

The issue here is that you're setting values to a record that does not exist. If the Record List is empty, you are indeed setting values to a record that in the end is not being used anywhere.

What happens is that, in order to prevent it from giving you a Null Reference / Object has not been initialized error (like the ones you'd get in C# and the like), the Agile Platform will indeed initialize the Record List with a dummy Record, but since that record is not effectively considered "data" by the Record List - hence the "0" length - it doesn't matter whether you're assigning to it or not.

If, however, you append a blank record to the Record List, and THEN assign the data to that record, then I would assume it would work as expected.

If you're in the mood for debunking this issue, let us know if it works when you go down that path :)

Regards,

Paulo Tavares
Sorry for the double post.

Just following up on the last post, what you're doing there in fact is reading from the dummy record in the Record List, and the data has not been erased by the .Net Framework's garbage collector yet.

However, a Table Records - or any other list widget - will focus on the Length and Empty attributes to decide whether or not the list has data, since it always has that dummy record there by default.

Regards,

Paulo Tavares
@Paulo

"Just following up on the last post, what you're doing there in fact is reading from the dummy record in the Record List, and the data has not been erased by the .Net Framework's garbage collector yet."

That is something that I was unaware of, but since you have described outsystems behaviour when dealing with recordlist/records, it now, makes alot of sense.

1 other question how do you, "assign a value to a record with a value, then output the record onto the screen without using an expression".

If interested, here are some test performed on record and recordlist http://dl.dropbox.com/u/678582/Outsystems/TestAnimal.oml


Hi Robert,

Well, to start it off, take what I said with a grain of salt. While that's the way I remember it being implemented, the gory details might actually be more elegant and I'll stand corrected by any of our R&D guys any time, if they want to share more details about it :)

As such, regarding your question about assigning a value to a record with a value, then outputting the record onto the screen without using an expression, I would assume it to be seamless.

I mean, if you have a Record that already exists, and has values, if you want to change one or some of its values, I usually just use an assign node and change it right away.

However, if you are changing the value in a screen action, and ending it with an End node, probably you should be changing the Record in (suppose) TableRecords.List.Current.Record.Attribute instead of the original one you loaded in the preparation (i.e. Query1.List.Current.Record.Attribute) since the preparation does not run the second time around and so, unless I am mistaken, you will have to change the variable in the widget directly - either in the ShowRecord, TableRecords, ListRecords or whatever.

Once again, however, if you're working on a list, it needs to have a real record there.

Let me know if this makes it clear - and if it addresses the specific scenario you're referring to. If not, do give me a couple more info on the exact problem you're facing :)

Regards,

Paulo Tavares
Paulo

For an example, lets take a real life scenario, where you built a web service, with a method called GetItem, GetItem, has a GetItemRequest record input structure, and a GetItemResponse output structure.

GetItem [method]
GetItemRequest
-API_Key [Text String]
-API_Secret [Text String]
GetItemResponse
-Success [boolean]
-Error [Record]
-MyItem [Record]

After the application verifys the API key and password and everything is ok, the getitem responses with the MyItem record, if you assign a value to the myitem record structure before returning it in the GetItem response, its not going to work! Unless you make MyItem a recordlist and use Listappend, after you assign the values, or if the record was assigned from a value from the database that would work aswell but you just want to response with a predefine setting or configuration from a variable, it will not work. (at least from the test data it does not work!)

 
Hi Robert.

I attached a revised Animal eSpace with comments of my own in either action. The problem, as I mentioned before, is that you were changing, in a screen action, the variables themselves, and not the Widgets.

However, if you are changing the value in a screen action, and ending it with an End node, probably you should be changing the Record in (suppose) TableRecords.List.Current.Record.Attribute instead of the original one you loaded in the preparation (i.e. Query1.List.Current.Record.Attribute) since the preparation does not run the second time around and so, unless I am mistaken, you will have to change the variable in the widget directly - either in the ShowRecord, TableRecords, ListRecords or whatever.

Once again, however, if you're working on a list, it needs to have a real record there.

See the eSpace for an example of what how it could be done, and my comments on the ones that I've corrected, as well as the ones that don't work.

However, I'd expect your web service to work correctly, the way you described, unless you didn't explain it properly.

Let me know if this helps!

Regards,

Paulo Tavares
@Paulo

"I attached a revised Animal eSpace with comments of my own in either action. The problem, as I mentioned before, is that you were changing, in a screen action, the variables themselves, and not the Widgets."

I thought it would work, because the variable value was assigned to the TableRecord widget via Source Record List and the EditRecord variable has also been assigned via "variable", (this is what is shown in the property field).

So you would think agile platform would use these properities and it should work, but unfortunately it does not work that way.

---
More importantly, are the following test results.

Updated: http://dl.dropbox.com/u/678582/Outsystems/TestAnimal.oml

After further testing, it shows that, you are right the web service does work correctly as you have suggested! 

Now compare how the "API_GetItem" action was implemented in a webscreen and how "API_GetItem" action was implemented in a web service method "GetItem", you will find that both logic has been implemented in the same way,  however the result differ.

When API_GetItem action was tested in a webflow, the test fails,
When API_GetItem action was tested in a web service method the test was successful.

Used same action/logic, same implementation, different results! 
Hi Robert,

Somehow my answer wasn't posted.

I looked into your eSpace, and the problem is exactly what I posted before. In the web screen example you're assigning the result to the local variable, instead of assigning it to the widget directly. As I mentioned, when you change the local variable in a screen action, the widget's variable is not bound again to it, and that's why it won't work. What happens is that the screen's actions are .Net postbacks, and we keep the viewstate, changing only what is needed - but we do not re-bind the variables.

In your case, in the GetItemTest, if you assign the action result not to the GetListResponse variable, but to EditRecord1.Record.GetItemResponse, it should work. That is the same logic.

Let me know how it goes.

Regards,

Paulo Tavares
@Paulo

Firstly would like to say that there is no technical issues to solve, the inital problem has already been solved in the first few post above. 

Additional test was later further conducted to help get a better understanding of how record and recordlist are handled by the agile platform, and it has lead to a misunderstanding of wordings used to describe two certain properity "Source Record" and "Source Record List" .

----
Initally it was believe the same logic was used, and below is the reason for making this suggestion, where it could be confusing to a developer.

 
 
As you can see from the image attached above the description clearly states that the "GetItemResponse" record variable is the *source* used to populates the widget ie "The record variable that populates the widget."
 
Therefore in technical terms, this would mean the "source record" properity is assigned with the values contained in the "GetItemResponse" record variable. At least that is the behaviour a developer would expect to occur with the description describes above. (and it does get assigned only before the screen gets rendered as described below).

"What happens is that the screen's actions are .Net postbacks, and we keep the viewstate, changing only what is needed - but we do not re-bind the variables."
Yes this explains completely everything! it now tells me extactly what is going on here! and why the action does not work in a web screen and only works when used in the web service method when using a local variable.

Since the viewstate does not get updated when an action is triggered when using a local variable (even when the ajax refresh is used) - this tells me that if we were to trigger the action using the local variable, just before the screen gets rendered, we will get the desire result from the web screen presentation as expected using the local variable, because the local variable will be assigned to the editrecord variable just right before the screen gets rendered and this is when the viewstate is created (the viewstate is created when the load events are triggered)


But I still think the description is somewhat misleading ie when a local variable is assigned a value, and used in the source record properity, when used  an ajax refresh, the developer expects it will  "populate the widge with the record variable", and update the views on the screen, because thatis what the description tells him it would do, can you see how the description used for "source record" and "source record list" could be mislead and confuse developers? 


EDIT: the description is somewhat in a sense correct, but the behaviour produced is not as expected, would this be considered a bug since the ajax refresh does not update the variable used in the source record, source record list?
Hi Robert,

Well, I'm not sure if it qualifies as a bug per se, but since it's something that is not clear, I'll send over the feedback to our documentation team. :)

Regards, and keep up the great work.

Paulo Tavares
@Paulo 
 
"Well, I'm not sure if it qualifies as a bug per se, but since it's something that is not clear, I'll send over the feedback to our documentation team. :)"
 
The description is clear but the behaviour is unexpected. As mention previously the source record and the source record list describes that it populates the widget using the variable contained in the source record/source record list, but it does not populate using the variable like it says it would. It would only populate on first load this is when the viewstate is created, which is standard behaviour, but isn't that what the ajax refresh action is for? to refresh and update the view state/screen elements? 
 
Let me know what they say,when asked "Could it be that the source record/source record list property has not been implemented properly? or the ajax is broken?" Strange behaviour. Hope it gets fixed :)
 
"Regards, and keep up the great work." 
 
No worries.
@Paul

By the way if you test the eSpace application and use a Late_Load on the submit action, the correct values are displayed on the screen, but that is expected behaviour since we already know that the viewstate for the record/record list is created and retained onload. :)


Well,

What the Ajax Refresh does is it re-renders solely the part you chose to be refreshed, and sends it back over to the end-user's browser. You don't get to re-create the entire viewstate and bring it over again, otherwise that would imply re-rendering the entire page, with all widgets re-bound to the newly created viewstate - thus defeating the purpose of refreshing a smaller area of the screen using Ajax. That's the reason why the widget is not re-populated.

Populating something occurs only once - after that, it's already populated, and you manipulate the data in the widget.

I concede that it's reasonable to expect it to work as you describe - though that's a stretch from saying that it hasn't been implemented properly, or being broken :) It's been a design decision.

I'll forward the change request.

Regards,

Paulo Tavares
@Paulo

"I concede that it's reasonable to expect it to work as you describe - though that's a stretch from saying that it hasn't been implemented properly, or being broken :) It's been a design decision."

You could correct the behaviour's *feature*/bug by mapping the source record or source record list variable to the editrecord behide the scene, ie if the developer does not do this  himself, and you see that he added the variable as the source properity, you would instantly know what the developer was expecting to achieve from this since the developer has added the local variable to the source property he expects the local variable to be used as the source - and that would make alot of sense, for everyone? :)

However it if the record or record list is used as a local variable within the application action but has not been added as the source record or source record list, then you are to do nothing, because the local variable is not the source so you do nothing, this would be considered standard/expected behaviour.

This should not affect any logic code that was once created previously! If you add a local variable as the source it would means you want to use it as the source, hope this makes sense and outsystems consider correcting this feature :)
@Paulo

"You don't get to re-create the entire viewstate and bring it over again, otherwise that would imply re-rendering the entire page, with all widgets re-bound to the newly created viewstate - thus defeating the purpose of refreshing a smaller area of the screen using Ajax. "
 
Agree that makes sense!
Hi Robert

I've been reviewing the entire thread, and took a look at your espace (TestAnimal), and I think you're experiencing a by design behavior specific to the Edit Record widgets. Let me clarify.

The Edit record widget has a slightly different behavior then the other widgets regarding the postback (either through submit or ajax). It's the only widget that will use the source record only once to populate it with inital values, and even though the source record will remain accessible on the screen actions, change it will never affect the Edit Record during postback, because it will never realod the values into the edit record from the soruce record again.

This behavior is documented on the Service Studio help for the Edit Record Widget Properties, with the text section:

"Record used to populate the Record runtime property with the initial values. The source record is only used once, immediately after the preparation when the screen is loading. Afterwards, the user input is kept in the Record runtime property and it is not assigned back to the original Source Record."

The reason for this by design behavior, is to guarantee that the postback of the screen with an Edit Record, will not lose the user's input. This was a feature introduced on the Agile Platform 4.0, detailed at http://www.outsystems.com/NetworkForums/ViewTopic.aspx?Topic=What's-New-in-OutSystems-Platform-4.0#Post4 .

So if you want to update the expressions inside the Edit Record, you should update the Edit Record widget runtime record variable, instead of the source record variable, in the screen actions.

Hope this information is helpful in understanding the behavior of the Agile Platform

Cheers

Miguel Simões João

@Miguel,

Thank you for clarificating, and the link to the support document.

Since the "source record" and "source record list" properties has clearly been defined in the support document, no change to the properities featured behavior would be necessary, and probably something outsystems would not want to change anyways, but you do not have to change the behaviour at all!


Below I suggestion an improvment for clarification.

The suggestion is to rename 

"Source record" properity to "Initial source record"

"source record list" properity to "Initial source record list"


Problem solved :) 


This allows outsystems to keep same the original design behavior as before and also clarify the properties item behavior within the IDE.

(When a persons sees "source record", intantly he/she will think this is the "source record", because that is what it says it is, and you do not have the document open on the screen or see that the description stating that this source record/record list will only be initalised once on first loading, this he will have a problem and wouldn't know it until experiencing it, 1 word makes a whole lot of difference for clarifying this properity. Its not going to help me, but the next developer as the defination would be clearly stated within the IDE, at the point of development).

EDIT: I hope none of these suggestion or test conducted and post written in this thread is seen as offensive, but rather I would like to help improve the software and make it better for every other developer that uses outsystems. :)

"The suggestion is to rename  "Source record" properity to "Initial source record", "source record list" properity to "Initial source record list""

The problem with that would be that when reading "initial X", one would also suspect a "subsequent X" which in this case there is none.

Hello

@robert and @Killian: thank for the suggestion, I'll forward it to the OutSystems R&D team, and although they may not choose that exact same renaming, they will evaluate the best way to hint the developer that there's a different behavior for the Edit Record.

Your suggestions are always welcome, and in fact  we at OutSystems promote user suggestions to improve our products, and the Wisdow of Crowds application is a sample of such committement.

Cheers

Miguel Simões João