In Intrexx, passing parameters from one page to another, involved a little of programming in the past. Passing parameters to portlets was basically impossible. However, with version 19.03, United Planet introduced two new features. Parameters and a remastered Portlet-Framework.
While portlets were around for some years now, parameters are completely new. In my previous post about building a customer-dashboard, I already used both. In this post I want to go a bit more into the details. I also want to explain how it changes the application landscape inside an Intrexx portal and the basic architecture of Intrexx applications.
Since version 19.03 application developers are allowed to add parameters to a page.
Parameters have a name and a data type. They can be marked as required. You can decide if the parameter is only required for new records, existing record or both. This is, when the page is assigned to a data group. You can also set an option if it is allowed, to transfer the parameter via request. This means it can be transferred as part of the URL to the page.
A required parameter needs a value. If it doesn’t receive one, the browser will raise an exception.
You can add several fallback values. So that if the sender didn’t pass a value for this parameter, it still receives a fallback value so that your logic doesn’t break. Apart from the obvious value that may be a number, string, date or boolean, you can also add a semantic value. A semantic value is something like a name tag. While the name of the parameter is sometimes predefined(e.g. STRID is the name of the primary key column), a semantic value can be whatever you like it to be. Using the semantic value, you can pass the value of a parameter with the name PARAM_A to a parameter with the name PARAM_B. Therefor the name of the parameter isn’t vital when calling the page.
There are several areas where parameters are available for further processing. They differ in their basic purpose. One is processing the parameter, the other is passing parameters to a page. You can find the specifics in the Intrexx Online Help.
With version 20.03 United Planet improved the filter dialogue of tables and other controls, to support parameters. This is the area where parameters will be used the most.
Bindings also support parameters. You can use bindings as the value of a control, to filter data and you can access them from scripts. Intrexx offers specific objects to access the Bindings from Groovy and Velocity. Bindings contain all kinds of Intrexx context objects, e.g. user-session and parameters.
Parameters need to be passed to a page whenever the page is loaded. You can load pages from buttons, tables, calendar, charts, emails, push-notifications, portlet-containers and more.
As buttons, tables and most of the others exactly know which page they load, they also know the names of the parameters. With portlet-containers it’s quite different. You can allow any portlet from any other application to be available within a portlet-container. From the portlet-containers perspective it’s impossible to know which parameters each portlet needs and what their names are. That’s why there are semantic values. Portlet containers send parameters that might not fit the name of the portlets parameters.
As I wrote before, portlets are a part of Intrexx for a long time now. In the past it wasn’t really possible to control which portlet should be shown on what page. The result was a very long list of available portlets. Also it wasn’t easy to make portlet-pages responsive.
All this changed with the remastered version of the portlet-framework.
Taking a look at the portlet-tab of a page, there are three options that jump the eye. The first one is the option to reveal the portlet to other applications and portlet-pages. Usually portlets are only available inside the current application. This is for not overcrowding the portlet-list of all the applications.
The second and third are for restricting the availability of the portlet. One is to restrict the selection and the other to restrict the display of the portlet. Both require a Groovy script that returns either true or false.
Before the new portlet-framework there was only a hard-coded version of the portlet-container with no possibility of setting options. The new portlet-container offers options similar to the ones from the portlet-tab before. You can either restrict the portlets to some of the current application, or allow portlets from all applications. In addition to that, you can restrict the available portlets with Groovy scripts. Different from the Groovy scripts before, the portlet-container expects the scripts to return a list of portlets as a result.
On the second tab you can pass parameters to all the portlets, called by this portlet-container. If a portlet requires a parameter, but the portlet-container doesn’t pass it, the portlet won’t show in the browser. Here you can also add semantic values to the parameters. So that if the parameters name are different from the ones the portlet needs, Intrexx can still match them and pass the value.
What does all this mean for future Intrexx portals? In my opinion, the combination of these two features might change the application landscape and architecture of Intrexx portals fundamentally.
Until now, there was no clear separation of concerns in Intrexx applications. So if a requirement was “add documents”, the developer usually added this to the app. The same is true for similar requirements like “add comments”, “add task-management”, etc.
If you wanted to split this functionality up into several applications in the past, it involved a lot of processes or scripting. This however resulted in a large ball of spaghetti-like applications and processes, that were linked together. It was impossible to pull one of it out of this and replace it by something else.
With the portlet-framework you can change all that. You can now build a document application, a task-management application, a comment application or any other application. And you can now integrate all these applications by the use of parameter and portlets, without them knowing each other. This will result in a much wider range of applications that will offer more depth in the future.