Scriptable and queryable select fields

Published on December 23, 2015 by Jan Haderka



Six months ago, I used my talk at the Magnolia conference to speak about how to create a dynamic select field (a drop down, if you like) in just a few minutes.

In that case, the field obtained data from a REST service. People repeatedly asked for the code - if you are looking for it too, you can find it under my GitHub account

What I want to show you today is a bit different. I happened on this idea when I drove back home after visiting our Basel office, and coded it on the way (while my colleague Tomas was behind the wheel, I would obviously not consider coding and driving).

Anyway, this was the initial goal: rather than having all of you write additional, dynamic selects in Java, and you having to compile and deploy these, I wanted to see if I could achieve that at runtime without ever leaving Magnolia.

And I'm happy to report my success here and today (though it's only partial). You still need one extra Java class for it (which I have conveniently packaged up for you in a separate module), but after that you should be good and dynamic pretty much forever (as long as we are talking about select fields, that is).

So what it is you get after installing the module?

It comes with two types of select fields.

 

Scriptable select

 

With this select, you are able to specify Groovy script as a producer of your select field values. The script can be as simple or as complicated as you want - accessing external services, DB, reading data from JCR or just iterating through an array of values. It's up to you. The only condition is that the script returns the list of values at the end. To make it even simpler, upon installing the module, it will load a sample script in the groovy/scripts workspace for you.

 

 

I'm also providing you with sample configuration of the field that you can just extend (or export as yaml, if that's what you prefer to work with).

 

Queryable select

 

This is similar to the scriptable select - actually, it takes the scriptable select to another level. If all you want is read values from a JCR workspace, and if using a link field is not a good option for you, you can use this select field to specify the JCR search query, which can be as simple as "SELECT * FROM [mgnl:contacts]". Specify the type of query (jcr, sql-jcr2, xpath) and then provide little "scriptlets" that read the label and the value from the node returned by the query you specified earlier, such as "n.firstName + " " + n.lastName" where "n" is the current node. Can't get much simpler than that, right?

As with the previous case, a piece of sample configuration is bootstrapped, so that you can just extend or copy whatever you need.

 

 

You might wonder if the name of the node variable has to be "n" in the scriptlet. And the answer to that is yes - that's how it is. However, you have to link to the defining script in the field, so feel free to change it there if you like, and add even more functionality (or limitations).

Maybe just one word of caution - when you enable/use this select field, you are giving power to the people who have access to the config to execute the scripts - something that is normally reserved to those with access to the groovy/scripts app/workspace. So while this should normally be the same group of people, in a case of a tightly configured environment, you might be escalating their privileges. Consider yourself warned :)

Enjoy!



Comments



{{item.userId}}   {{item.timestamp | timestampToDate}}

About the author Jan Haderka

Jan is Magnolia's Chief Technology Officer. He has been developing software since 1995. On this blog, he'll write about Magnolia's connectors, integrations and coding ...with the odd Magnolia usability and development tip thrown in for good measure. He lives in the Czech Republic with his wife and three children. Follow him on Twitter @rah003.


See all posts on Jan Haderka

Demo site Contact us Free trial