Variable sys_id in widget server side script

[ohhgr]

Hello All,

I was stuck on this particular point and hope someone can point me in right direction.

I want to create a reusable widget (say a modified date picker), I would use it as a variable in multiple catalog items. Now, I'd like some options to dynamically change based on some options specified at the variable definition. (I could store them in a different table in future, but for simplicity assume that one additional field stores this information on 'item_option_new' table. My question is how can I identify which variable is being called in widget's server script?

In client controller I can get this information by using $scope.page.field.sys_id. But, I'd like to have this information at the server side so that I could provide the options from server side.

-Mandar

[ohhgr]

Hi Regina,

I'm not sure how I can use any server side script to identify the sys_id of the variable that is using it.

As shown above, I'm using these instances of the same widgets. At the moment I'm passing the sys_id from client controller to server side script in widget and that way populating different options. But, I'm looking to avoid that and (somehow) get the variable's sys id at the server script itself.

-Mandar

[Community Alums]

I hope I interpret your question correctly (I had the same problem).

I have realized in the mean-time that widgets really don't work like jelly.

The pages/variables are not constructed at all on the server side, they are built on the client side.

I suppose that is why the widgets have instances in service portal pages.

But option schemes/widget instances are not available when a widget is used as a macro.

What I did as a quick fix, was:

- define a custom instance table to store instance data for all macro widgets on all catalog items (if needed - of course)

- load all instance data for each instance of the same widget on a catalog item, when the widgets' server side code is executed

- when rendering on the client side (and when the widgets can identify themselves), look up the correct instance data for each widget and use it.

E.g. if - say - widget_1 is used three times on item_1 (var_1, var_2 and var_3), then I would load the instance data data_1, data_2 and data_3 three times (for each run of the server side code of widget_1). Then, when var_1 would be rendered (on the client side), I would look up which one of the instance data items data_1, data_2 and data_3 is for var_1 and I would use it. Then do the same for var_2, finally do the same for var_3. Kind of deferring building the widget controlles' „data" object for the client side. Of course this is not an optimal solution as the same data is loaded as many times as instances of a widget on an item. But for now I have not found a way to only load instance data once, without modifying OOB portal pages. Still looking for that solution. Perhaps an extra macro widget that would hold just instance data for all macro widgets on a catalog item and then, by signaling through the root scope would provide that data for each macro widget instance upon „request"?

[ohhgr]

Thank pok,

Thanks for sharing your experience. What I ended up doing was load all the related information while the page loads and store that information in a client side variables as an JSON object. And I assume that I'm getting this information while writing the code for the widget.

Although, its not the best approach, it still helped me getting what we want.

Hope that helps.

Mandar

[xiaix · Accepted solution]

I completely understand what you're trying to do... or so I think.  I'm in the same boat.

I have a catalog item on the Service Portal to where I added a macro variable that loads a widget:

Now, when this widget loads, I want to grab the sys_id of the calling catalog item because in the Server Script, I want to query the item_option_new table to get the sys_id's of all the variables:

When the widget initially loads, it runs the Server Script and that's where I can't seem to get the sys_id of the calling catalog item... the same issue you're having.

The only way that I've found do what you're trying to do is by doing this:

However, this is not the way I want to go about it.  I need to grab that sys_id before any of the HTML Template code gets rendered.

I forked this into my own question in the Developer Community here (my Developer Community post)