I use the Database view/plugin in InelliJ IDEA quite often.  It’s actually become my “go to” editor for SQL scripts because of it’s responsiveness, the fact that it’s right there inside my IDE and the code completion and join hints are often times better than the DBMS vendor’s offering.  It’s pretty easy to open a new console to start writing queries once you’ve set up a datasource.  You can click the ‘SQL Console’ icon in the toolbar, or right click on the datasource and choose ‘Console’:\

One of the handiest features of Grails is the “flash” scope.  The flash scope is “A temporary storage map that stores objects within the session for the next request and the next request only, automatically clearing out the objects held there after the next request completes.”  It’s a handy way to send messages and errors around when dealing with form posts and redirects.  Since I’ve been working with Spark Java I’ve found myself missing this little feature so I decided to throw together my own implementation.  I’ve added the following closure inside of my main() method in my Bootstrap class:

The latest journey in my quest to see just how many new technologies and frameworks I can learn in one week involves Morphia.  Morphia is a “Java Object Document Mapper for MongoDB”.  In other words, it let’s us map our POJOs and POGOs to MongoDB Documents and persist them in MongoDB.  \

Right, so, on to the codes.  To get started with Morphia declare a dependency as such:

compile group: 'org.mongodb.morphia', name: 'morphia', version: '1.3.1'

Obviously you’ll need to make sure you’ve got access to a running instance of MongoDB before you try to connect/persist to it.  Next, create a domain class - we’ll call this one Person:

In the last post we looked at how Thymeleaf handles reusable layouts.  A reddit user enlightened me about an open source ‘dialect’ for Thymeleaf that makes it behave in a similar manner to SiteMesh.  It’s documented pretty well, but...

Yeah, documentation can be boring sometimes, so I thought I’d put together a quick post on how that would look in the Spark Java application I’ve been working with.  It works well, but it suffers from an inability to pass model variables to the layout template.  That’s something that SiteMesh can handle (although in a less-than-elegant manner in my opinion) and in my view it is almost deal breaker.  Something as simple as a nav menu that is common across all pages will ultimately require some dynamic data, and if we’re going to need to th:insert the fragment on every page, then what are we really gaining by using this style of layout template?  I’ll add how I’d think this could be handled at the end of this post, but first let’s look at how to implement this dialect in the project.

Just a quick update after my last post to clarify things a bit.  I mentioned in that post my dismay regarding the inability to pass model variables from the child view to the parent layout - and I shared that concern with the dialect developer Emanuel on GitHub.  He quickly wrote back to clarify that it is indeed possible:

Hi Todd! First of all, nice blog - I came across it the other day when you wrote about using Thymeleaf w/ Spark \

The next step in using Spark Java with Groovy that I would like to look at is getting data into a view.  With Grails, we’re used to using GSP pages - and they work great, but Spark Java doesn’t have view support out of the box.  Instead, it let’s you choose a template engine.  The alternative is to simply serve static HTML pages and retrieve any data via Ajax calls.  That’s a valid strategy in some cases, but most sites will require some level of dynamic data in the view and requiring Ajax for all of that data isn’t always the best solution.  Enter Thymeleaf.  In their words:

In the last post we looked at plugging in Thymeleaf into a Spark Java application for view rendering.  The concept was pretty simple: using the Thymeleaf engine, render a view with a map of variables to use as the model.  But in reality, our applications need a bit more complexity.  They need reusable layouts.  In this post we’ll take a look at how to handle that with Thymeleaf.  

Reusable layouts include things like headers, footers, scripts and other things like nav menus that are common across the application.  Thymeleaf accommodates these by using what they call “fragments” - reusable blocks of code defined by the th:fragment attribute that can be called from your templates using the th:replace, th:insert or th:include attributes.  You can read all about it in their docs, but let’s take a look at a practical example below.