Reuse and combine XPath constraints - using constraints like primitive types - Mendix Forum

Reuse and combine XPath constraints - using constraints like primitive types

26

How often do you repeat the same XPath constraint in your Mendix apps?

How much time do you spend on refactoring your app, when this constraint must be changed?

For example if you look at access constraints on two related entities you have these 2 (and this is a very simple example)

//Area[M.Access_Area/M.Access/M.Access_User='[%CurrentUser%]']

//Item[M.Item_Area/M.Area[M.Access_Area/M.Access/M.Access_User='[%CurrentUser%]']]

Wouldn’t it be easier to maintain, if you could define your area access constraint:

{AreaAccessConstraint} = [M.Access_Area/M.Access/M.Access_User='[%CurrentUser%]']

//Area{AreaAccessConstraint}

//Item[M.Item_Area/M.Area{AreaAccessConstraint}]


There are similar cases for constraints on pages, where multiple grids share the same constraint and only differ in an additional filter.

And would it even be possible to write XPath constraints as variables, detached from an actual query, to dynamically build retrieves?

This would add so much flexibility to all kinds of queries while keeping the power of XPath expressions.

What do you think?

asked
3 answers

This idea is simple and strong, I believe it would be a game-changer for big projects. It would make it easier and faster to build and take care of apps while making everything more consistent and secure. 

It would create benefits across the platform:  in microflows, pages/widgets, and in setting domain access rules.

 

In addition to the idea: It would be really nice if we could use XPath snippets within the XPath snippets.

Created

This would be very awesome. Even only a way that you could fill the xpath constraint by inputing a string would be helpful. Then you can enter your own logic to create the right string to input to a database retrieve. Too often it happens that you cannot make a reusable microflow because the database retrieve is slightly different on for example attribute level.

Created

I think this is an excellent idea, not only for dynamically building retrieves but also for maintainability on changes in a subquery that is used in multiple grids, entity access rules or otherwise (unfortunately the vote button is broken at the moment, but you will have my vote later ). The subconstraint could be a separate item in studio pro and accessible like you would use constants (or maybe integration as part of the “Data Set” functionality, to make that more powerful?)

 

(Edit: missed a feature that is already available, although not for legacy widgets)

Created