calling UserName from parent login component UX issue

[jrodder]

Hello! Was wondering if anyone could help me with an issue I'm currently having. Basically I have a main component, nested as an embedded object inside a login UX component. I am calling the UserName field and writing that to a control inside the child UX, using:

var po = {dialog.Object}.getParentObject();
var userId = po.getValue('UserName');
//alert(userId);
{dialog.object}.setValue('userId',userId)

that works, but only once! I am guessing that because the lookup is going to an unbound field, there's really nothing left to look up after the event fires initially. What would be a good way for the child UX component to be able to call that original stored variable until logout?

[Davidk]

Re: calling UserName from parent login component UX issue

What events are you using?

[jrodder]

Re: calling UserName from parent login component UX issue

Well hello again there David. onRenderComplete, and onPanelActivate. I put that similar code into a button hoping to be able to test that way as well.

[Davidk]

Re: calling UserName from parent login component UX issue

So your code is in both onRenderComplete and onPanelActivate?

[jrodder]

Re: calling UserName from parent login component UX issue

Yes, identical code in both places. If you submit a record, or refresh the page it seems to lose the username. It will only work once after logging out and back in again.

[Davidk]

Re: calling UserName from parent login component UX issue

Sounds like a logic flow problem. You're logging into a UX and during the login process you're setting an unbound control named 'userName', in the parent UX, with a user name value.

Then you do something which activates the panel that houses your embedded component. Code in the child UX grabs the parent, grabs 'userName' and sets the child control 'usedId'.

Then you're refreshing... what? The parent UX? How? Browser refresh? And... because of your active session... you're still logged in... but your 'userName' control is now empty... because you refreshed the UX and have not filled it with anything... because you don't need to login... which is needed to trigger setting the 'userName' control.

So... I'm guessing this is a Web app... not a Mobile app... because you're refreshing stuff. There's probably a bit of other info missing as well. You mention submit a record... where... child UX? It's data bound? Are you refreshing the page after you submit? Why would a Parent control get cleared when a child UX submits.

I think you need to be very specific about what gets cleared... where... and after what action.

I'd guess that the Parent control gets cleared after a refresh. It's unbound and you're not setting it again because you're already logged in.

The child control gets clears after a submit because it's a bound field... and you're probably setting up for a new record (although you haven't said) and you're not doing anything to reset that control.

[jrodder]

Re: calling UserName from parent login component UX issue

Sorry yes, I was trying to ask a general question without giving all the details. The login component I am using is the template provided in the software. The embedded UX is for technicians to submit a record into the database. I am not refreshing the parent UX, I was testing within my laptop browser because I do envision these guys trying to also enter records using the same application, even though it's designed for mobile. If I have to craft an a5w page for computer use, and the other one be dedicated for mobile only that's fine too. It's just that the same thing will happen regardless if I am using the browser on a phone, or the browser on a laptop, at least after submitting the record. At no point am I refreshing the parent UX, I was referring to the browser refresh.

So yes, is the issue more that I need to preserve that userId after the record gets submitted. It sets up for a new record. Maybe something needs to live in the submit button or elsewhere to grab what is living in that control and set to a variable for use in the next record?

[CharlesParker]

Re: calling UserName from parent login component UX issue

That sounds like a session variable in ondialog initialize would work perfectly, if the username is coming from the security tables alpha already has a built in function to get that, and you can set that as the DEFAULT value which would work every time there is a new record. If that's what your after every maybe someone will point out the function, if not I will post it when I get home I can't remember stuff off the top of my head. You wouldn't even need a session variable then.

[Davidk]

Re: calling UserName from parent login component UX issue

Since you're working with a web page... not mobile... and you're refreshing, then you should use a session var. Plus... make like easy for yourself and use state variables as well.

In your parent UX, in the server side onLogin event, set a session var to your username...

session.userId = userName (whatever var your username is in)

Then, in your embedded UX, onDialogInitialize event...

e._state.userId = session.userId

Then... in any javascript you create in the child... you can do this...

var myUserId = {dialog.Object}.stateInfo['userId'];
alert(myUserId);

In your embedded UserId control you could set it's default value to...

=session.userId

or in javascript...

{dialog.Object}.setValue('userId',{dialog.Object}.stateInfo['userId']);

There are other ways to "publish" session vars so that the client side of a UX will see them... but I'm not so crazy about that. State vars are much easier to deal with.

[jrodder]

Re: calling UserName from parent login component UX issue

Wow yes, thank you. This looks like exactly what I was after. I was reading about session variables but that post made things much clearer than the documentation I had been reading. I'm slowly accumulating more knowledge as I work with this, as well as some of the other data driven apps I'm making for our company. It's a bit late on the weekend for me to play with this tonight, but I'll implement and post back to let you guys know how it went. I had another issue trying to use a lookup function to actually write the PK from the tech table into the form, but I solved that with an ON INSERT trigger if/else on the SQL side of things.

I was indeed confused regarding the *mobile* term, I was thinking in terms of it rendering on the mobile device. Obviously that's still just a web page. Maybe one day when this is all working properly I'll explore making a proper mobile application using the same base.

[jrodder]

Re: calling UserName from parent login component UX issue

That sounds like a session variable in ondialog initialize would work perfectly, if the username is coming from the security tables alpha already has a built in function to get that, and you can set that as the DEFAULT value which would work every time there is a new record. If that's what your after every maybe someone will point out the function, if not I will post it when I get home I can't remember stuff off the top of my head. You wouldn't even need a session variable then.

I would be interested to see this also, yes. Mainly to see how it compares to David's way of attacking it. Yes, all the usernames will be living in the security tables.

[CharlesParker]

Re: calling UserName from parent login component UX issue

put
=a5ws_getcurrentuser()
as the default value for the field. It will always be the logged in username for a NEW record.

[jrodder]

Re: calling UserName from parent login component UX issue

put
=a5ws_getcurrentuser()
as the default value for the field. It will always be the logged in username for a NEW record.

This worked just fine! Thank both of you guys for helping me out. I now have a pretty basic yet functional application. I do need to do some reporting and have that automatically filter based on the userId, but I will tinker and attempt to learn that without too much hand holding. I am going to watch this video

many times, as it seems like it's chock full of the session variable information I need to keep going.