Banner Developer Skills, What is Groovy, What is Grails
Groovy and Grails for Ellucian (Sungard) Banner Developers
A Free Tutorial
>> Kenneth: It’s typical of people with the Banner background. When we talk to people in a university or just generally an academic background working in an academic IT department, typically we find a lot of database knowledge. People are very familiar with databases, but the programming background doesn’t tend to fall into an object-oriented category.
There are exceptions to that. Pretty much every school I’ve talked to, there’ll be one or maybe two people who’ve done some Java or some C++ or maybe one of the .NET languages like C Sharp or VB.NET, but that’s about it. They don’t tend to have a huge object-oriented background. It tends to be familiarity and maybe working with a little bit rather than a lot.
Also, on the issue of web applications, there tends to be some experience on the web application, maybe using PHP or something like that. Sometimes it uses more extensive things like Java web framework with Servlets and JSPs, but not really that common not that much. Of course, you have lots and lots of experience with the Banner product and there’s a lot of experience using the various mechanisms inside Banner like Oracle forms or other plugins.
Before we dig into the meat of it, let’s just figure out what some of these terms mean. What are these things is all about. First of all, Grails is a framework. That means it’s basically a partially constructed web application. It’s an app that already exists with the plumbing and the routing and everything, already ready to go. You’re just supposed to plug in your controllers and your domain model and customize your view the way you want and Grails will take care of the rest.
Grails, as I’ll demonstrate for you, has a lot of real convenience features, a lot of mechanisms to make it easy to build a web application very, very quickly.
It’s relatively new. Grails has only been around for a few years but it works all the way from the view back to the database and back. What makes Grails really different from many of the other application frameworks out there is that Grails builds on existing technology. Grails is not trying to say reinvent the flat tire, which is what I’d like to say when people try to reinvent the wheel and they get it wrong.
Grails is based on existing open source freely available projects that are very popular in the Java industry – things like the Spring framework and Hibernate. Grails simply uses the Groovy programming language to customize how those applications work, how those underlying tools work, to make it very easy and effective. This makes Grails a rather interesting blend of old and new. It rest on these older foundations, these very mature technologies. Of course, everything has been revised and customized to take advantage of as many of the newer developments as possible.
It’s heavily involved in the term they call convention over configuration. There are not a lot of config files, there’s not a ton of XML you have to manipulate or anything to get things to work. Mostly, if you do things the way Grails expects you to do them, then everything works just fine. You don’t really have any issues with it at all. If you do things the way Grails doesn’t expect, then you have some customization ahead of you and possibly some work there in the code as well.
One of the interesting features of Grails from the Banner point of view is that – again, if you use Grails the way it’s intended to be used you should be fine. It should be relatively easy and especially those people who do not have an extensive object-oriented background, that’s probably going to be your life for the first few months or whatever amount of time your startup time in using the technology is you’ll do things the way Grails prefers them done, and that way you’ll still be able to stay relatively productive while you’re filling in this additional background assuming you’re interested in doing so.
It’s an open source technology. Everything can be downloaded for free including the source code. I’ve done that on many occasions and, frankly, that’s not a bad way to learn some things about it, not that I dig into the details of the source code itself but good open source projects tend to be loaded with test cases.
In a real way, test cases are like executable documentation for open source. So while the documentation may or may not be great – in some places it’s excellent, in some places it’s a bit weaker – the test cases will tell you how the technology is intended to be used. I tend to look for those things and dig into that.
The Grails in general, if you follow its conventions, it’s a very easy framework to use, very easy to deploy and work with. Basically, the deployment story comes down to the same as that for Java. If you’ve got an application server that supports Java, then you can deploy a Grails app the same way would’ve deploy any other Java application and it’ll work just fine. I’ll talk about that more a little bit later.
How can a version 1 product be mature? Grails is currently at version 1.3.5. That’s the version I’m going to be using when I do a little demonstrations today. How can you call something like that mature? Again, it’s the underlying technologies that are really where the maturity comes from.
The Spring framework is a technology in the Java world that is pervasive pretty much throughout the Java industry. It does a lot of what they call dependency injection, it handles the life cycle of objects. I like to call it a Swiss Army chainsaw. It’s this massive framework that really touches pretty much every API in the Java world and makes them simpler and easier to use.
Hibernate is a technology that is designed to work with databases and to convert database tables into objects, and back again. The term ORM there means it’s an Object Relational Mapping tool. It turns object-oriented elements like classes and objects into relational tables and back.
You have to provide the mapping. You have to tell it how to do this. But once you tell it what the mapping is from your classes to your tables, Hibernate takes care of generating all the SQL and executing it all and opening and closing transactions as required and everything. It’s a very powerful technology, very mature. Both Spring and Hibernate are version 3 or above.
SiteMesh is an open source technology for handling the view, assembling the view out of various pieces inside of a webpage, basically. There’s some Ajax libraries that are built-in, prototype, scriptaculous, a couple of others, I think. I think they’re moving toward building in jQuery. Any libraries that aren’t there, you can easily install through a plugin mechanism.
Quartz is an open source product to allow you to schedule jobs like Cron jobs or whatever, so that things will run on a periodic basis. There’s a plugin for this that works with Grails immediately.
Where does Groovy fit in? Groovy, in one sense, is Java. It’s not really Java. It’s a separate language but Groovy compiles to Java bytecodes. Java runs by running on what they call virtual machine, a Java Virtual Machine, the JVM that you install on whatever platform you want to use. It could be a workstation, it could be a mainframe, it could be a PC, it could be a Mac, it could be whatever. That’s the heart of this whole write-once-run-anywhere idea is that you write your code in Java, you compile it to these bytecodes (whatever the heck a bytecode is) and then run it on the virtual machine. Groovy may be a separate language, but it also compiles to bytecodes that run on the same virtual machine. Anywhere where you have Java installed, Groovy can run as well.
Groovy basically takes Java and simplifies it in many ways and enhances it in many other ways. Groovy is a very comfortable language to work with for Java developers. Java developers learned it very rapidly. There’s a whole family of new languages that work on the JVM, Groovy is one of them.
Of course, there are others you may or may not have heard of called, for example, Scala or Closure is another one. There’s a language called JRuby which allows you to run Ruby code on the JVM as well. Of all of these languages, Groovy is by far the easiest for Java developers to learn and to use.
Where does it come in to this picture? Groovy is good on its own. I tend to use Groovy a lot on its own for simple scripts or even for a fairly extensive programs, but Groovy is also the language that ties all those pieces together in Grails, all those underlying technologies like Spring and Hibernate. Spring and Hibernate are written in Java and they will always be written in Java. Nobody’s going to port Spring to Groovy. It’s fine just as it is.
Hibernate, of course, I shouldn’t be quite so blunt that Hibernate is in Java, there’s also an NHibernate version that runs on the .NET framework as well, but what we’re dealing with is the Java aspect of it.
Those are already in Java so that means that the Grails framework itself is basically dominated by Java code, but then Groovy is used to tie everything together and to make DSLs – those are domain-specific languages. One of the ones I’m going to demonstrate for you very briefly is something called GORM which stands for Grails Object Relational Mapping or Groovy Object Relational Mapping. I forget which one. Either way, it’s a simple way to map your domain classes to database tables.
Groovy, as I mentioned, is a programming language. Java has been around now for about 15 years and that’s a fairly long time in the IT world of course. Groovy is a much newer language and therefore its able to clean up some of the inconsistencies on Java, make some of the Java features a lot easier to use and also bring in newer developments in the programming language world like Closures or Builders etc. We’ll see some examples of that pretty shortly.
It all works with Java compiles to the JVM. It is a compiled language. It’s much more efficient than an interpret language, etc. But you can write scripts as well as classes. Again, it’s an open source project.
How is Banner going to deal with all these? I have talked to many people who work at SunGard. I’ve talked to people at conferences. I’ve tried to get involved as much as possible, but let me be blunt right at the beginning. The true answer is we don’t know for sure how Groovy and Grails are going to be used inside a Banner or maybe some of you do – I certainly don’t. What I do know or at least what I’ve heard is that the first Banner module that it tends to incorporate Groovy and Grails will be the student module.
They’re supposed to announce at the next major SunGard conference when all this is going to happen. But the strongly backed rumors suggest that this new student module be rolled out probably around the middle of the year. Somewhere around June, I believe, is what they’re aiming for. Of course, that’s all unofficial but that’s the plan.
The idea certainly is to be for Grails rather to be another replacement for Oracle forms. I don’t believe, by the way, that they’re going to remove anything. I don’t think that they’re going to deprecate any existing applications or make it so you’re forced to rewrite anything that already works. Frankly, I’ve always take the philosophy if something already works, I’ll leave it alone. I don’t think you need to necessarily port any of your existing applications over to Groovy or to Grails. But if you want to build new applications then I believe these are going to be options that will be available to you.
We don’t know exactly what they’re going to do, but I know what Groovy does and I know what Grails does and therefore we can make some educated guesses as to what their role inside of Banner is going to be. Grails is a pluggable extensible framework that does much more than web applications but it’s still used by and large for web applications. So chances are, if you’re going to be building web applications that take data from an HTML screen and then create domain objects from it and manipulate them and apply business roles, etc. then send up a result, Grails is the technology that is a very natural one for that sort of use case.
Groovy itself of course appears in Grails, but I wouldn’t be surprised if the Banner product will allow you to specify some of your business rules inside Groovy as well.
Business rules can be very simple scripts. They can be very powerful applications. That’ll be up to you. But I wouldn’t be surprised if using Groovy as one of the languages to create your business rules will be supported. I’d be surprised if that was not supported. Maybe I should say it that way. How many double negatives shall I throw in here? Let’s try it this way. I imagine Banner will support both technologies.
Anyway, that’s where I’m headed with this. One of the things I do want to address is what the learning path would be for people who are Banner developers really heading into Groovy and Grails. I’ll get to that a little bit later.
How does the Java world see web applications or applications in general? This is for people who have not been in the Java world very much and their exposure to web applications has been through certain other technologies somewhat simpler ones like PHP or ASPs or something like that. I don’t mean ASP.NET. I mean Active Server Pages in their original form.
Most Java applications are built around a layered architecture. The idea is that you’ll have a presentation layer which is where you’ll take in all your data and when you display things to the outside world, and then when you submit data to the application probably through a form then that will go to some kind of controller. A controller’s job is to possibly validate the input data, but then it’s really to play traffic cop, figure out where do you want to go from here.
Therefore controllers don’t generally have a lot of the business logic embedded in them but they instead call classes that do the business logic. These days that layer tends to go by different names like middleware or business layer or something like that. Nowadays it tends to be referred to as a service layer. That’s where your business logic resides. That layer is the layer that talks to the persistence layer which is where your mapping to the database takes place.
If you have a database with lots and lots of tables in it, say there’s a table called “student” or a table called “course” or a table called “instructor,” then your persistence layer will be the set of classes whose job it is, is to turn those tables or table rows into objects and back again. Say I get a new registration for students signing up for a course. That registration and the updated course information will be in object form in the persistence layer and then that layer will save it to a database.
The service layer will be there to do transactional stuff as well. It’s basically saying, “If we only had one class and one table, life would be very, very simple.” It’s when you introduce relationships that life gets complicated on many levels I should say.
At any rate, if I was modifying the student table and the course table and say registration table and then the instructor table, I wouldn’t want to start and stop a transaction for each one of those table manipulations. Instead, I’d like to have one transaction that encompasses the entire modification, the entire insert, if you will, or update as the case may be and those transactions are managed in the service layer. The controllers figure out where you want to go. The service layer supply the business logic and then they work with the persistence layer to save everything in the back end. Pretty much any Java-based framework that you encounter will be designed around this type of architecture.
The other term that I use but I didn’t really define earlier is the term MVC. That stands for Model View Controller. This is an architecture that’s been around with us since the small talk days back in the ’60s and ’70s, maybe even earlier than that.
The idea here is that controllers and views talk to each other. A controller will pass information to the view. The view will submit information to the controller. Both of those will use model objects. The view will access the information out of it. The model will pass the view for display. The controllers create model objects and modify them. If any of this stuff is reusable, it’s the model. The model doesn’t necessarily know anything about the view or the controller.
The views and the controllers tend to be fairly tightly coupled – everything to accessing the model goes through the view or the controller. You don’t access the model directly in any of these.
This is a figure that was – I guess the term would be “reused” from Wikipedia.
Let me just start this thing off by building a little Grails application for you and give you an idea what these things look like. I have here a tool called SpringSource Tool Suite. This is built on an open source editor called Eclipse. I’m going to build a little Grails application here.
Let me say, “File New,” “Grails project” and I’ll call it a quest because if we’re going to deal with Grails, we might as well search for the Holy Grails I suppose. That sounds bad. As you can see, running this simple – yeah, that was really horrible. I understand.
>> Gary: It had to be said.
>> Kenneth: All I can say is it will get worse before it gets better.
As you can see, by running that single command saying, “Make a Grails application for me,” a whole lot of activity suddenly happens. The Grails scripts start right up, they start in a directory, they’ve build an application for me building a whole bunch of source, folders and folder for controllers and services and domain classes, and I have views with layouts inside them. Internationalization, configuration, a whole set of testing, directories including unit testing.
One of the things that’s meant by convention over configuration is that every Grails application created builds an identical structure to it. We’ll customize it by adding our own domain classes or controllers or services, but if you encounter Grails application from someone else that you’ve never seen, the layout will be exactly the same. You’ll just have to go in to the appropriate directory and figure out what they did.
Then there were a lot of other code generation that went on and eventually I wound up with what I have in here is a project called “quest.” In here I have a controller’s directory and a domain directory, etc.
Grails tends to favor domain-driven design. That means you build your classes representing your domain objects, your students, your course, or what have you and then Grails favors this. Once you have this, then you can start customizing what to do with them in building your business logic and everything. Let me build a new domain class here.
Right now the issue I’m having – it’s not really much of an issue – is that I’m running on two different screens, so when I click on a button here it pops up a window on a different screen. Let me do this in a slightly different way. Let me say under Grails tools to create a domain class this way. That way I think you can see it right there.
I’ll call this com.skillbuilders.quest. Then I want to make a class called a quest here.
Again, that triggers a script to start happening.
Now we see the code that was generated. I’m hoping this font is big enough. If it turns out this font isn’t quite big enough for you to be able to see, please let me know and I’ll increase another size.
This is the class that’s going to represent my quest. Quest should have a name. There we go. I’ll get to this constraints block in a moment. But frankly, I already have enough in order to execute my quest ¿ in order to run the project. Run as a Grails application. Let me let that start up.
There are three different environments. There’s the development environment, there’s the testing environment and there’s a production environment. Basically, what changes in those cases is which data source you’re going to use and also the ability to reload classes on demand.
I now have a URL. This is using an embedded Tomcat server. I didn’t have to set that up or anything, it’s already built. When I click on this, you see I have Grails application, available controllers.
Oh, I forgot to make the controller. That’s not good. Let’s put in a controller. Wait a minute. Under Grails tools, Grails controller and I will call this com.skillbuilders.quest.quest again, and that will build a Grails controller.
Now I’m going to use one of these really cool built-in capabilities. That’s called scaffolding.
This says to Grails, “I want you to generate a set of webpages to create and index and update and find quest objects.” All I had to do was to run that. This was to create this single line and save it. Now I think I can go back to my webpage here and hit “Refresh” and now there’s a controller. When I click on that link, there I have a webpage that says “Home” and new quest and there’s an ID and a name. If I say I want a new quest, I can put in a name which is to seek the grail.
Now I’ve created a quest and I can edit that and say, “Let’s change that to a lower case G or something and go update,” and it’s there. I can go to the quest list and I see there’s my quest. If I make a second quest, which is to learn about Grails, then I can go back to my list here and I can order them by name by clicking on the name column, alphabetically or reverse order. I can go back and order them by ID or reverse by ID, whatever you like. I can even go to the learn about Grails one and say, “Let’s delete that one” and it’ll say, “Are you sure?” I say, “Okay.”
There you go. I mean that’s pretty good. That’s a lot of code for or a lot of results for basically putting in one line of code and telling it to use the dynamic scaffolding. All of those webpages are dynamically generated now. This is a really comfortable way to work while your domain model is still changing. Once your domain model settles down, then you can build the static scaffolding. That’s the one where you’ll see all the code and start making changes to it.
I’m going to build this one up a little bit more but then I’ll switch to an application that I’ve already constructed to show you some of the power that’s available in this.
>> Gary: Ken?
>> Kenneth: Yes, sir?
>> Gary: Can I ask you a question from Jennifer?
>> Kenneth: Sure. Absolutely.
>> Gary: Where was it currently storing this data?
>> Kenneth: Good question. Inside the configuration area is a file called DataSource.groovy. This is all Groovy code, by the way. This is showing us that embedded inside of Grails is an HSQL Database, Hypersonic SQL or just HSQL as they call it. That is a pure Java file-based database. In this case, it’s storing it in a memory version of this so everything’s in memory right now. It’s not being saved in a database at all really other than this in-memory version, which does support queries and everything.
In my more fleshed out application, I’ll show you a bigger version that actually uses MySQL for the database. This is MySQL. Changing databases is very simple. You just modify the settings in this file and drop the database driver into the lib directory and you’
Copyright SkillBuilders.com 2017