REST/GRID/FILTERS, should be simple but...

I’m still in the evaluating process for Mendix, I understand I’m not skilled enough yet so forgive me if I’m asking something really basic but, unfortunately I’m stuck and reading the documentation or searching the forum didn’t help so far. I also understand that there are, as always, several solution to the same problem, I would like to understand which practice should be considered the ‘best practice’. What I’m trying to achieve is to fill a grid view with data coming from a REST service and filter out some rows based on a drop down menu dynamically populated with some data provided by the REST. I do not have control of the REST that can’t be modified, therefore that can’t be achieved using the prebuild gridview/rest functions. The REST needs also a date as parameter and the GUI should allow to quickly moving back and forward between the dates with 1 day increment/decrements. The following screenshots shows and existing application I’m trying to replicate with Mendix. Status: - I can read data from the REST, map, and show in the grid.  - I can pass the parameter to the REST creating the object when I call the page (is this the way to do it?). - I can’t populate the drop down menu and use it to filter the rows. - I can’t refresh the grid view when the date changes using the back/forward buttons. - I don’t know how to filter out rows based on a specific condition (worked hours = 0) Any help is greatly appreciated so I can keep my Mendix journey going further, but please keep it simple.  
3 answers

There is not a single possible solution here, it depends on the specific business needs you are trying to achieve, on the expected load and several other factors.

Let's assume the simple situation where the dataset is small enough to download all relevant data into the Mendix database before use. and that the rest response is a one dimensional array of tasks.

You could do this in two steps:

Do a rest call to retrieve the tasks and store them in an intermediate persistent TaskImport entity in Mendix. The attributes match the rest response exactly.

For each task, normalize into a useable domain model, meaning eg you link tasks to minor projects and minor projects to major projects using a one-to-many associations.

When this is done, you can use a datagrid to display the tasks and the defauk datagrid search features to filter tasks based on major and minor project. And of course on number of working hours.

I hope this gives you a small push into finding a solution that fits your exact needs. I do suggest involving an experienced Mendix developer for architectural decisions like this. There are so many possibilities and practical experience really counts here.


Hi Michiel,

Thank you for taking time to look at my post. I understand and agree with your point and indeed I mention that there could be several ways to approach the solution. I know I can populate a local entity and doing that will open the access to the already embedded features of the Grid object as envisioned by Mendix, but I don’t like that solution. I already have a well normalized and organized domain model, so I just want to use it via API or connecting to it (that is what I’ll try next) even if that means move some logic from the server side to the client side.

Anyway, the final question is: one of my skilled programmers can develop that simple (in my vision) interface in some hours, is Mendix helping me in reducing that time?



I can get this from zero to production ready in one hour using Mendix, including

  • download and install of Mendix studio pro on an empty laptop
  • starting a new project
  • creating doman model, interface and UI
  • CI/CD implemented
  • full DTAP hosting
  • enterpise grade security & performance


In my experience, developers claiming the same productivity levels in high code solutions tend to forget about installing the IDE, starting a project, CI/CD setup, database scripting, hosting, integrating UI and backend and more.