Three quick tips for Magnolia app development

Published on November 26, 2014 by Jan Haderka

A few weeks ago, I published a script here that helps you generate new Magnolia apps in practically seconds.

From the feedback I received, quite a few of you took advantage of it - that’s always good to hear. In what will be hopefully a series of posts, I’ll show you how to change various configurations or extend your apps to achieve a better user experience.


Tip 1: Turn off inline editing

When you generated an app with my script, you might have noticed that when double clicking on the name of any node, it opens for inline editing. While I personally find that very handy for certain types of apps, it’s not suitable for all. If you want to change that behavior, all you have to do is go to your apps, and find the following properties in the Configuration app: 




Set them both to false. A piece of cake! Now, when you double click, the item doesn’t open for editing. In fact it doesn’t do anything. That’s probably not so ideal either, so let’s think about what our user wants to do by default. I’d bet that editing the item is probably of interest. Can we enable this somehow? 


Tip 2: Enable item editing

Sure, in the Configuration app, find (or add) /modules/blog/apps/blogs/subApps/browser/actionbar@defaultAction and set its value to the name of the action you want to perform as a default, for example editMyItem. If you are not sure what the name of the action should be, have a look at /modules/blog/apps/blogs/subApps/browser/actions. Under this node, you will find all the available actions for your app. All set? Reopen your app and check it out - double clicking on the item name will open said item for editing. All good. You might also notice that the default action is invoked not only on double click but also when simply pressing enter while having items selected in the workbench.


Tip 3: Expand folders easily

Now, imagine an app where you have some hierarchy of folders. That should be quite common, right? Why else would we be using a hierarchical storage for it. All you really want in such an app is to open a folder and reveal the content underneath when double clicking. How can we achieve that? 

This operation is normally done by the presenter directly, not by the action - so it will be little trickier. First, we need to create such an action. The implementation of that is quite trivial: get the WorkbenchPresenter instance injected into your action by Guice; in execute() method call presenter.expand()on the selected item. If you don’t want to code the action yourself, you might want to get one available here compiled and added to your instance. To get it working you will also need an appropriate action definition. Compiled? Good, all that remains is for us to add this action to our app. Under 
/modules/<yourmodule>/apps/<yourapp>/subApps/browser/actions create a new action, say openFolder and set its class property to our action definition class 

You probably also want to set the availability of this action. To do so, create an availability subnode under openFolder. To keep it simple, just add an extends property there and point its value to the availability of the addFolder action by setting it to ../../addFolder/availability. The action is created and set. Now, all we want to do is set it as the default action described above. Done? Cool, let’s go, reopen our app and try double clicking on some folder. Oops. Doesn’t work. To make it worse, there’s an ugly stacktrace in the console. What happened here? 

We asked for the presenter to be injected in our action, so Guice tries to oblige. But it does so by creating a new instance of the presenter which is not configured, and definitively not the one our action wants to manipulate. So what now? First, we need to add our workbench presenter instance into list of parameters to choose from when creating the instance of our action. To do so, we customize BrowserPresenter and include the workbench presenter in the list of parameters it passes on. We do so by extending BrowserPresenter and overriding its prepareActionArgs()method. To save you the pain, you can find such an extended presenter here. Good, so our action will get the presenter, now we just need to make sure that our app will use the presenter. Unfortunately this is not something we can configure in the repo, so we need to change the module descriptor of our module (I guess you had to create one by now anyway, even if you didn’t have one originally, to place all the classes we wrote here somewhere. So go ahead - modify your module descriptor to add the following snippet:


If you don’t know where in the module structure the descriptor is, and you used a Maven archetype to build it, look at src/main/resources/META-INF/magnolia/yourmodule.xml. Rebuild your module, redeploy and try out. All works now. Double clicking on folders opens them. Cool. That should be enough for one day.


What’s next?

And, as a little teaser, here are some of the other things that I’ll cover in future blog posts:

  • image providers showing thumbnails composed of a mix of images from items in the subfolders
  • having different default actions for different kinds of items in the app
  • having choose dialogs showing different things when being opened from other apps
  • and whatever else i get to hear from you as interesting!

Photo credit: Len Matthews


{{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