Adding a Web Block to a page dynamically

Adding a Web Block to a page dynamically

I am currently working on a project to allow a user to add a web block to their page from a list of available web blocks.  Is there any functionality in outsystems to pull a list of web blocks from the existing application in order to display it in a combo box or something like that?
Hi Jason,
I don't know if there exist some application in forge that does that kind of thing, but a easy solution is put the web blocks availables inside a container, one web block inside one container and for each container set, on the display setting, an expression that validate if the container with the web block will be showed or not.  Then you create a combo box where you show the options you want and then when the user choose one of them an variable will hold one value, and this is value that you will use to validate the expression on the containers, If the expression is True, the container will be showed, if it's the expression it's False, then the container will not be showed. I don't know if it's a solution for your problem or if is the best way to do it, try to see if make sense for you.
Gonçalo Azambujo
Hi Jason,

Just a teaser but I think you are better of teaching OutSystems Platfrom to that user and have him build his pages :)

EDIT: You can use IFs and a user configuration on a database table that you'll have to program to indicate what web block to show on that page. Can you drill down a bit on what you want to build, why is this need to have the user select which web blocks are shown on the page? Thanks!
Just as mentioned, it's not too hard to do.. one solution is to add all web blocks to given page. Setup a configuration variable along with if widgets to turn on and off specific web block. (this solution is ok when you don't have many web blocks)
Thanks Gonçalo and Robert.  Unfortunatly, the application that we are trying to build will potentially have hundreds of available "widgets" to add to a users page, so we cannot load them all (even hidden) when the user requests the page.  

André, the goal for us is to create a single web page that is able to be personalized and saved, sort of like the old "iGoogle" concept where people might choose an "rss Feed" widget and a "weather" widget etc... and add it to their personal page, which would be persisted.
Jason -

We did something very similar to this a few years ago. We made a "library" of dashboard widgets and let people add them to a screen, rearrange them, etc. So I can tell you that it is well within the technical abilities of the platform (and no, you do NOT need to resort to using backdoor, unsupported methods to make this work).

Here's what we learned:


* Looks good in a sales demo.

* Provides powerful functionality to those that use it.

* Looks great in a sales demo.

* Checks the "dashboard" box when we compare to competitors.

* Looks AMAZING in a sales demo.


* Can be very slow & resource intensive. If each widget takes... say... up to a second or two to run (reasonable in our case, they are pulling real-time reporting numbers)... and someone loads the screen up with widgets... it makes the screen slow. Guess who gets held accountable? US! So the end user has constructed a disaster of a UI for themselves, then blames us for it being slow... and it kills our servers in the process.

* No one uses it... I pulled numbers a few weeks ago, we have 7,000+ users with access to the dashboard, in one week we saw 500 total hits to it, half were the same user.

* No one...I mean NO ONE... knows that you can do the customization. Again, 7,000+ users in the system have access to these dashboards, and there are a very small number of custom layouts, and each one is a slow performer because so many widgets are on them.

* The widgets look gorgeous (have I mentioned that our sales team loves demo'ing them? ;) ), but the information on them is poor. We have a bunch of items in the "library" but none of them really say "this is the state of your business". Instead, users have to look at a bunch of them on the screen and combine things like "revenue per month" and "customers lost/gained per month" etc. in their head to say, "is my business improving or declining?"

* It took nearly a month to put together. A lot of that was self-inflicted, we insisted on doing drag/drop and at the time the Forge's drag/drop stuff did not work well for us (we wanted multi-column drag/drop). That's changed... we put our drag/drop component in the Forge and I know there's another one out there too that looks good.

* Drag/drop is not a common paradigm on the Web. People don't realize they can use it. Even the couple of folks who customize don't know they can drag/drop. Drag/drop was not an effective use of our time.

* Even without drag/drop it is a lot of time/effort to create, test, and maintain each of those widgets.


* If you are really set on doing this, I'd be glad to detail for you what we did. There's nothing technical stopping you from doing this.

* If I went back in time, I'd take the numbers from the system today, go to the project planning meeting and argue for a static dashboard page that shows a pre-determined list of widgets. Let us tune it for performance, give them the best possible experience based on what we've learned, and make sure that the 4 - 8 widgets give them actionable information instead of throwing a bunch of "data" at them to try to figure out what the actionable information is.

* This was an expensive project in terms of man hours and continues to be a drag in terms of headaches and maintenance.

* The big benefits we got were "checking the box" on feature set and looking good in sales demos.

Again... I'd be happy to share with you the "under the hood" of what we did... but our experience with a very similar project was not positive, and not for technical reasons.

Thanks Justin,

I am very familiar with difficulties surrounding user acceptance of new technologies, so I see your frustration and have experienced it first hand in other projects as well.  I am still curious about the technical aspect of how you were able to manipulate outsystems to perform this functionality without simply embedding custom js to do it.
Jason -


Here's what we did:

* Made a Static Entity representing the list of Widgets. It's not automatic to pull them, but it's a small item to maintain.

* Made a block for "Widget". In the block is a bucnh of If's based on that WidgetId to display the correct Web Block. Nothing fancy/automated here, but again, it's a few moments of work and not a big deal.

* Made a "Dashboard" entity that defined a Dashboard name, who owned it, etc.

* Made a "DashboardWidget" entity to tie Widgets to Dashboards, and added in an X and Y value representing which column and distance from the top it was.

* We limited the dashboard to 3 columns because of the width of our widgets.

* On the Dashboard screen, we had 3 Containers (one for each column) and in each one was a RecordList Widget with a Container, and inside the container we had our Widget Web Block and passed it the ID of the Widget to load.

* We made a Dashboard editor that allowed Drag/Drop and had an "Add" system to take Widgets from the "library", add them to the screen and move them around.

All easy stuff, except the drag/drop which was a hassle. Sure, it isn't going to be quite as automated as pulling a list of Web Block from a DB somewhere, but given the effort to make any given Widget in the first place, we felt that the work to add a Static Entity Record to enable it just wasn't a big deal.

Hope this helps!

Hi Justin,
Very cool stuff! Thanks for sharing pros, cons and your overall experience. Kudos to you!

Thanks Justin, that helps alot with the construct of dynamically displaying blocks.  I'm still trying to determine if it is possible to get a list of public web blocks from all apps in outsystems and display them in a combo box or list somehow.  Sounds like you did that part manually.
Jason -

Yes, did it manually, but it takes but a few seconds to add it in, while the Widgets were hours or days each to write... really not a big deal.

You aren't likely going to find an enumerated list of Web Blocks anywhere... I've never seen such a thing. :(