Not possible to use a variable of type "Object"?

Not possible to use a variable of type "Object"?

  

Hello, I was wondering why I cannot send an object variable to another server action. In the screenshot you can see it is clearly there and in the correct scope. I am using the HashTable plugin and if I want to add add a key to the hashmap I need to send the hashmap object to the action but it won't allow me. Is this a bug? 

(See the attachment for the screenshot)

Hello Joeri,

Could you show the error message?

Cheers,
Eduardo Jauch

EDIT:
I would say that the problem is that the input is not of the same type as the variable.

Hi Eduardo,

As you can see in the attachment, it doesn't show the variable in the "Locals" folder, but it's definitely there as you can see on the right. It looks like I can only access that variable in the Preparation :(

Hi Joeri,

As you can see from the image bellow, there is no problem to pass variables of type Object to input parameters of type object.

If Hashtable is not of type Object, you can use ToObject to convert it.
So, my question persist:

What is the data type of the "Hashmap", and what is the data type of the input parameter "hashtable"?

If I am not mistaken, some data types my not appear in the list, when you are trying to select a value for an input parameter, if the data type does not match.

Cheers,
Eduardo Jauch

Ok. I got it.

You are in a Screen Action (the Notify).
A screen action does not have access to variables of type Object declared outside them.

If you move the variable to the Screen Action, it will be available.

Cheers,
Eduardo Jauch

The types match, I double checked it. It seems that with server actions you can use variables of "Object" type, but not in screen actions. Can you verify that for me too?

It is like I said before.

You can use. The problem is that variables of type "object", defined at the level of the WebScreen, are not available in the ScreenActions. Only the ones declared at the ScreenAction level are available:

Ah I didn't see your other message. But I also have to use it in the WebScreen so I can't really move it to the ScreenAction right? You have to see it like a global variable which is accessed in multiple places (that's why it is in the WebScreen section, just like the other variables which ARE accessible).

Why is it exactly that I can't use "Object" typed variables in screen actions by the way?

Solution

Hello Jori,

This seems to be a "bug", but I had inquire the support to verify it.

Cheers,
Eduardo Jauch

Solution

Thanks, if you can keep me posted on the status that would be great :)


I will :)

This is not a bug.

Variables of type Object can be anything - even expensive objects such as file streams or database connections. You cannot create an Object in the preparation and expect it to remain in memory for the seconds or minutes before you execute your screen actions. That is well taken care by the platform, by not allowing you to do so.

Try to refactor your screen in order to remove this dependency between the screen actions and the preparation.

Thanks Leonardo,

It is good to know. It was something that i thought, but found it strange. Is this really a "feature"?
I don't remember to see in the documentation such restriction (doesn't mean that it is not there).

In any case, as I think it is not possible to use an Object, or convert it to anything "inside" OutSystems, this is a bad desing choice (I think).

For example, I can be dealing with an extension where I need to keep the state between calls. The only way I see it is through an "object". I can use a Session Variable (I think), but this would be even worse than allow to use a local variable at the screen level...

While I think that being cross module, it would be doing a copy of the object, what would have a very negative impact in performance, depending on the size of the object...

Cheers,
Eduardo Jauch

Hello Eduardo.

I've checked the documentation, and it's not mentioned there. So you could argue that it's an undocumented feature, or that it's a bug - we can't know for sure.

This is not just an OutSystems limitation, because you can find the same limitation in other web technologies. For example, how would you persist a hashtable in between multiple requests on PHP?

And even if you could technically do so, it would open a can of worms. When would you dispose of the hashtable? Never? Based on a timeout? What if, instead of a hashtable, the object was a database connection with locked resources? And how would you even handle the back button?

You cannot use Object in session variables in OutSystems, and Objects are never copied in OutSystems. So you have no option other than redesign your screen.

Depending on your use case, you could just use the database to persist the data. Or you could store it on the client side with javascript - if you only use ajax, that could be a way to persist data between multiple requests, without threatening the server scalability. Another option that requires more work is to serialize the object (into string or binary) on the preparation, and de-serialize when you need to use it on the screen actions.

Hi,

You can find that feature documented here:

https://www.outsystems.com/help/integrationstudio/9.0/Reference/OutSystems_Data_types.htm

Look for the Object part.

Cheers,

José

Hello Leonardo,

Thanks for the reply. I understand the limitations of web applications. The lack of an efficient way of keeping state, that require the use of database or the viewstate, is one of the reasons why web applications can not really be used in all scenarios (where the network latency is not a problem already).

But I think that besides the size (and I can have the same problem with a string, binary, etc), all other variable types have the same constrains: how to keep the values between calls? Then, again, other variables usually are smaller and have a smaller potential to cause bottlenecks.

And I also understand that OutSystems make a tradeoff here. In certain aspects it cuts flexibility to increase development speed and maintainability.

Its a good thing. But I'm curious why objects and not binaries?  Binaries, it seems to me, have also a very good potential to cause harm in performance.

Cheers

Eduardo Jauch

José Costa wrote:

Hi,

You can find that feature documented here:

https://www.outsystems.com/help/integrationstudio/9.0/Reference/OutSystems_Data_types.htm

Look for the Object part.

Cheers,

José

Hi Jose,

While I think Leonardo's reasoning is fair and that he is probably right in that this is a design choice (one that I can live with), and while the documentation really says that (not with this words), at least in the current version (10) is perfectly possible to create local variables of type Object (in server actions, screen actions and web screens). But it is not possible to use local variables defined at web screens on any other screen action that not the page itself (didn't try the preparation).

So, the documentation for version 9 is not applicable to version 10 in this topic...

Cheers

Eduardo Jauch


The documentation link that José provided only applies to Integration Studio.

Regarding why binaries can be used in screens, while objects cannot, the issue is that an Object can hold system resources like open files or database connections.

If you want to get down to the lower level, a binary variable can be serialized into the viewstate without any problems (you might end up with a very large viewstate, but that onus is on you). But a generic Object might not even be serializable, so there would be no way to store it on the viewstate.

A hashtable is a case of a serializable Object, that's why I suggested, as a last resort, serializing it to binary and storing the serialized version in a local variable.

leonardo.fernandes wrote:

The documentation link that José provided only applies to Integration Studio.

Regarding why binaries can be used in screens, while objects cannot, the issue is that an Object can hold system resources like open files or database connections.

If you want to get down to the lower level, a binary variable can be serialized into the viewstate without any problems (you might end up with a very large viewstate, but that onus is on you). But a generic Object might not even be serializable, so there would be no way to store it on the viewstate.

A hashtable is a case of a serializable Object, that's why I suggested, as a last resort, serializing it to binary and storing the serialized version in a local variable.

And we have to live with the limitations of the viewstate... :)

Thanks for the explanations, Leonardo.

Cheers

Eduardo Jauch


Hi Leonardo,

Thanks for the explanation.

Cheers,

José

Thanks for all the answers and insights guys. I think I'm stepping away from Objects then and creating my own structure for a dictionary. I think that works best in my scenario.