Creating reusable widgets?

[JennyHu]

Hi everyone,

I'm trying to wrap my head around the organization of widgets.

What is a widget package?

How is the widget package used?  

I know that when I create a widget in a scoped application, the package is set to the scoped application.   When using widgets outside of the scoped applications, the widget cannot be modified.   Configurations are done through widget instance options.

If I would like to create a library of reusable widgets to share across various scoped applications and Global (for IT service portal), what package should the widgets be created under? Would it make sense to create a scoped application with just re-usable widgets for sharing?

Thanks,

Jenny

[philengles]

Hi Jenny,
  Really happy to see people discussing the advantages to building re-usable widgets. When it comes to building re-usable widgets I won't sugar coat it; it can be rather confusing as a developer to accommodate for all of the potential options. However it will pay off dividends when other people can plug and play with your widget because of the amount of time saved plus it will help level you up as a developer. Re-usable widgets require you to think on a more abstract level your widget needs to be a flexible object that can react to variety of inputs and parameters. So I am gonna provide a couple of tips that have helped me improve building this style of widget.

First tip, its okay to "hard-code" some parts of your widget. If you are building a custom widget don't make it overly complicated especially during the brainstorming stage of how your widget will interact with the user. What does this advice really mean? Don't make testing your widget challenging on you! Make testing your widget and its core functionality that you are building and interacting with as easy to try as possible.

Why is this good advice?

  A) If you widget interacts with the "hard-coded" data how you want it to (You are now half way there and just need to abstract out your code one level further)
  B) You will start to see other problems that your widget will have to account for
    C) You hopefully didn't waste too much time accounting for problems that might not have actually been problems (apply to all things)

  D) Finally you will get a better sense of which inputs & parameters will be effecting your widget

Finally I wanted to give you some "real" advice instead of just how to approach the idea of a re-usable widget. You asked a couple questions and I'll do my best to answer them.
      I don't think you will need to create repository of "re-usable" widgets most of the widgets that SerivceNow constructed for their Service Portal is accessible to you on the table "sp_widget". It might be easier if you navigate to "sp_page" table and there you can see which widgets live on which pages. Your portals can share widgets, widgets are not limited to certain portals. With regards to scoped applications I would place the widgets that you want to share between applications in global scope. My understanding is that you wont be able to call/edit a widget from a different scope however that doesn't mean that you can not change scope and bring the widget with you. What are some hurdles and errors that these scoped applications & scope widgets are giving you? Please let me know if there are some more questions.

Best,

  Philip Engles

[JennyHu]

Hi Philip,

Thank you for a very insightful answer.   Much appreciated.

I think my questions came up as I'm developing for a scoped application.   When I'm in my scoped application, the package of the widgets I create automatically are set to the scoped application.   There is another developer in our organization that is developing widgets for IT service portal which is in the global scope.   To create re-usable widgets that can be shared and are located in a known"sharable" place, I need to train my mind to switch the application scope to global first and then create the re-usable widgets.   Why not create re-usable widgets in my scoped application?   Because, how would other developers know that there are re-usable widgets in my scoped application unless I explicitly tell them.

So, thus my idea of placing the re-usable widgets in a common place - a place that developers know to go to.   A lot of times, widgets may be very specific to each application.   However, I am hoping we can reduce re-inventing the wheel, cloning/duplicating widgets and create re-usable and easily configurable widgets to cut down on development time and future maintenance headache.   E.g. updates done on a widget, but not applied on the cloned widget.

Thanks,

Jenny

[philengles]

Very cool idea Jenny. At this point, I haven't seen anything that resembles what you are talking about. How many widgets are you presently dealing with and how many developers are you dealing with? Part of me thinks this is the nature of the beast but you also could create some supporting tables and reference your widgets that you feel are "re-usable". You could go one step further and widgets could have a parent-child relationship, one main widget that people do updates to in "global" scope and once updated mirror updates on the parent widget and will trickle the changes down to the child widgets (in a different scope). Let me know what you end up deciding to do to help with portal management. I am very interested in this idea and I understand the need for it.

Best,

  Philip Engles