nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

non-static object features? how? (with comment)

ATHANASSIOS_FAMELIARIS

Hello all (again)I need to feature in an custom item's WebNode object which will be unique to each instance created. i.e. I have a feature in WebNode called theList. This is used in Action-Create and the create weblingo. Right now, theList is the same for all items created (like static in java). It is possible to make it different for each item created? I have noticed some og Livelink's code does this. During debuging, some features have this (temp) prefix if I remember correctly. So does anyone know how to do this? Thanks!

Find more posts tagged with

Comments

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

If you don't want the data to be the same, then you can change the data in one of the _subclassCreate functions.

You can just write

.theList = { 'myValues' }

Creating a temporary object with OS.NewTemp(...) won't work, because there is no way to tell Livelink to use that temporary object in stead of the current object.

Hans

From: eLink Discussion: Development Discussion [mailto:development@elinkkc.opentext.com]
Sent: maandag 29 november 2004 16:37
To: eLink Recipient
Subject: non-static object features? how? (with comment)

non-static object features? how? (with comment) Posted by ap_stavzeti (Zeti, Stavroula) on 11/29/2004 10:32 AM

Hello all (again)

I need to feature in an custom item's WebNode object which will be unique to each instance created. i.e. I have a feature in WebNode called theList. This is used in Action-Create and the create weblingo. Right now, theList is the same for all items created (like static in java). It is possible to make it different for each item created?

I have noticed some og Livelink's code does this. During debuging, some features have this (temp) prefix if I remember correctly. So does anyone know how to do this? Thanks!

ATHANASSIOS_FAMELIARIS

That didn't actually do what I wanted, but I found a way arrount it. But, of course, I appreciate your suggestion. Thank you!Ys

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

I don't think my way is the best way to do it.

The way to do it in Livelink is to return the list as part of the (parm.)Response parameter. The data in the response parameter can be accessed via .fResponse in the webLingo file.

Hans

From: eLink Discussion: Development Discussion [mailto:development@elinkkc.opentext.com]
Sent: woensdag 1 december 2004 8:41
To: eLink Recipient
Subject: Thanks!

Thanks! Posted by ap_stavzeti (Zeti, Stavroula) on 12/01/2004 02:38 AM
In reply to: RE non-static object features? how? (with comment) Posted by hstoop (Stoop, Hans) on 11/29/2004 10:57 AM

That didn't actually do what I wanted, but I found a way arrount it. But, of course, I appreciate your suggestion. Thank you!

Ys

ATHANASSIOS_FAMELIARIS

What I wanted to do is be able to submit the form in the creation html, and be able to come back to the same page without loosing the values. Part of this I managed to to by using the request and response. But, for a reason too complex to explain here, I needed a place where I could store data to be passed between the Action-Create script and the create page. By using the feature this cannot be done, as the feature is the same for every instance of the object. (Hans, apparently, even if you set it from _subclasscreate)What I discovered was the LLAPI.Cache library, which allowed me to do exactly what I wanted using the database. Im just mentioning this here because I think it is a important, typically undocumented feature of OScript.Tell me what you think...Ys

Hans_Stoop_(hstoop_(Delete)_1579932)

Message from Hans Stoop <hstoop@opentext.com> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

HI,

I think you are talking about passing data between two different requests.

In livelink you probably have 2 different threads that handle the two different requests. The threads don't share any objects/classes.

In that case the cache functionality is indeed the only option.

Hans

From: eLink Discussion: Development Discussion [mailto:development@elinkkc.opentext.com]
Sent: woensdag 1 december 2004 15:59
To: eLink Recipient
Subject: Actually...

Actually... Posted by ap_stavzeti (Zeti, Stavroula) on 12/01/2004 09:56 AM
In reply to: RE Thanks! Posted by hstoop (Stoop, Hans) on 12/01/2004 02:51 AM

What I wanted to do is be able to submit the form in the creation html, and be able to come back to the same page without loosing the values. Part of this I managed to to by using the request and response.
But, for a reason too complex to explain here, I needed a place where I could store data to be passed between the Action-Create script and the create page. By using the feature this cannot be done, as the feature is the same for every instance of the object. (Hans, apparently, even if you set it from _subclasscreate)

What I discovered was the LLAPI.Cache library, which allowed me to do exactly what I wanted using the database. Im just mentioning this here because I think it is a important, typically undocumented feature of OScript.

Tell me what you think...

Ys

ATHANASSIOS_FAMELIARIS

Yes, indeed that's what I need. But since we'are talking about the creation of the same object, I was hoping that some object-oriented principles exist in Livelink. Apparently not in this case.I think the problem starts from the fact that no object is created until the user actually presses the Add Item button on the objects create page. I think this is a wrong approach, if some kind of temp object existed from the moment the Action-Create is executed it would make more sense. At least that's how I feel, being used to some object-orientation features. Just beacuse we have two diffeent threads, does not mean that they cannot share some memory.And, again, thakns for answering all my questions Hans!Ys

Magnus_S_(novnoruser_-_(deleted))

Remember that ....The only common place is what's stored in the database for all frontends...