Sunday, March 2, 2014

KRAD Training - April 14th - 18th

Training ​including ​the ​newest ​KRAD ​features, ​attend ​onsite ​or ​online, ​and ​super ​discounted ​rates! 

Training ​on ​the ​most ​current ​version ​of ​the ​Kuali ​Rice ​development ​framework ​KRAD! ​Training ​will ​cover ​all ​you ​need ​to ​know ​to ​start ​building ​great ​applications ​today, ​and ​support/implement ​migration ​processes ​in ​your ​current ​Rice ​applications. 

Kuali ​Rapid ​Application ​Development ​(KRAD) ​is ​a ​software ​development ​framework ​for ​building ​enterprise ​web ​applications. ​KRAD ​provides ​many ​useful ​features ​and ​helps ​greatly ​with ​building ​rich ​modern ​user ​interfaces. ​KRAD ​provides ​solutions ​to ​common ​technical ​problems ​such ​as ​a ​quickly ​building ​UIs, ​accessibility, ​security, ​CRUD ​operations ​(searching and ​maintaining), ​integration ​with ​identity ​management, ​and ​workflow! 

Register Now:

Who ​should ​attend? 

  • ​Developers ​who ​have ​worked ​with ​the ​Rice ​KNS ​module ​and ​wish ​to ​learn ​about ​the ​new ​KRAD ​framework ​for ​converting ​previous ​apps ​or ​writing ​new ​apps 
  • ​Developers ​who ​are ​looking ​into ​using ​Rice ​and ​are ​interested ​in ​what ​features ​the ​KRAD ​module ​provides 
  • Developers ​who ​have ​been ​working ​with ​KRAD ​but ​wish ​to ​deepen ​their ​knowledge 

What ​will ​the ​training ​cover? 

  • Overview ​of ​KRAD 
  • Overview ​of ​the ​UIF 
  • Types ​of ​Components 
  • Building ​Pages 
  • Adding ​Rich ​Behavior 
  • Spring ​EL 
  • Lookups ​and ​Inquiries 
  • Maintenance ​and ​Transactional ​Documents 
  • Using ​jQuery ​and ​Styling 

What ​skills ​are ​needed? 

Attendees ​should ​have ​experience ​with: 
  • General ​web ​application ​development ​(including 
  • HTML/CSS/JavaScript) 
  • J2EE ​Programming, ​including ​Servlets, ​JSP ​and 
  • JSTL, ​MVC ​Patterns 
  • An ​IDE ​such ​as ​Eclipse ​or ​Intellij 
  • XML 
  • Working ​with ​a ​MySQL ​database 
In ​addition, ​the ​following ​are ​recommended ​to ​get ​the ​most ​out ​of ​the ​training: ​Experience ​with ​the ​Rice ​KNS ​module, ​JSTL, ​Spring ​Beans, ​Spring ​MVC, ​and ​jQuery. 

Who ​will ​be ​giving ​the ​training? 

Jerry ​Neal ​is ​a ​Senior ​Developer ​for ​Indiana ​University ​working ​in ​Enterprise ​Software ​development. ​Over ​the ​past ​8 ​years ​he ​has ​worked ​with ​the ​Kuali ​project ​as ​a ​developer ​and ​development ​manager. ​Currently ​he ​is ​the ​lead ​architect ​for ​the ​Rice ​KRAD ​module. 

How ​can ​I ​attend ​the ​training? 

The ​recommended ​way ​of ​attending ​the ​training ​is ​onsite. ​Training ​will ​be ​held ​in ​Bloomington, ​IN ​at ​the ​new ​Cyberinfrastructure ​building ​( ​You ​may ​also ​attend ​the ​training ​online. ​Video ​from ​the ​training ​will ​be ​streamed ​and ​online ​attendees ​may ​interact ​with ​the ​instructor ​through ​online ​video. ​ 

Register Now:

Monday, December 9, 2013

Unified Kuali Processes

Thought I would take a moment to expand on a Kuali technical item that very recently arrived at a pretty cool milestone.

As of last week there are five Kuali projects (KS, Rice, Mobility, KPME and OLE) that all inherit from the exact same version of the latest top level Kuali pom (version 3.3.36)

Tops among the various benefits this provides is consistency, transparency, and simplicity for a number of critical software development processes.


Building any one of these five projects is done the same way as all of the others, and is one simple command:
$ mvn clean install
Any Kuali developer familiar with checking out and building any one of those projects, will be inherently familiar with how to do so for all of them. Any java developer (including the vast numbers of developers external to Kuali) familiar with Maven will also be able to easily complete a checkout and build. This can typically happen without them needing to speak to someone at Kuali or otherwise requiring extra assistance.

Given the community source model under which Kuali software is produced this is an invaluable asset in terms of enabling the extended global community to engage with Kuali projects and provide feedback. Since every ounce of friction removed from the build process is multiplied across all developers (both internal and external) this has a very positive cumulative affect over time.


Public copies of the project's software are automatically published and conform to a well known and documented standard.

Every project declares a globally unique identifier for every binary it produces.  In Maven parlance this is GroupId + ArtifactId + Version, aka "GAV". The identifying information gets automatically baked into the filename of every binary without exception.

Those binaries are then posted to Kuali's public internal repository and (at the project's discretion) to a globally accessible public repository that hosts them for free. This makes them automatically accessible to anyone, anywhere, at no cost to Kuali.

This is only possible because all five projects adhere to a few simple non-negotiable rules critical to keeping the worldwide public exchange of open source software organized and cohesive.


Technical information is automatically generated including javadocs that always exactly match the corresponding code.

The latest Kuali branded versions of these are at:  StudentRiceKPMEMobility, OLE
All content is versioned and permanently published to Amazon's content delivery network (CloudFront).

This enables:
  • High speed browsing (everything is cached to 31 different edge locations around the world)
  • Guarantees the content is always available
  • Is extremely low cost
Kuali's CloudFront costs for the month of November '13 totalled $4.07.  This represented 600,000 requests and 30 gigabytes of network traffic.  Interest in the content originated from around the globe and was serviced by Amazon data centers in Virgina, Ireland, Tokyo, Singapore, Australia, and Brazil.

There are any number of other benefits to having all five project teams use a shared top level Maven pom.  Economies of scale is one, (fixing or upgrading something in one spot benefits all five project teams simultaneously).

I've chosen to highlight these three since they:
  • Directly impact day-to-day development in a positive way
  • Demonstrate the pro-active steps Kuali is taking to be a good steward of the open source technologies it produces in a cost conscious way
  • Represent fundamental software engineering processes that have been abstracted out in a unified way for all five projects teams

Jeff Caddel
Director of Development Operations
The Kuali Foundation Inc

Friday, November 15, 2013

Kuali Days 2013

It's that time of year! Kuali Days 2013, our yearly extravaganza, will shortly be upon us. The Kuali Days conference is jam packed with informational sessions that range from project overviews for rookies, to new feature demos for veterans. This year Kuali Days will be held in San Deigo, CA, and has expanded to three days. For more information on conference logistics, see Kuali Days 2013.

As always, the Rice team and community has prepared many great sessions about the Rice project. In this post I will highlight some of these, and let you know of some other sessions I am looking forward to.

For Rookies

For those who will be attending Kuali Days for the first time, or are new to the Rice project, here are the introductory sessions.

Monday (Pre-Conference Workshop) 8:30 AM - 12:00 PM

Kuali Rice Installfest: Computer Setup for Rice Application Development 
Monday (Pre-Conference Workshop) 1:00 PM - 4:30 PM

Tuesday 8:45 AM - 9:30 AM

Tuesday 11:45 AM - 12:30 PM
This is one of two sessions I will be co-presenting on with Brian Smith. A good general overview of KRAD for those who are looking at the framework for the first time.
Tuesday 3:15 PM - 4:00 PM

Wednesday 11:00 AM - 11:45 AM

Thursday 9:45 AM - 10:30 AM

This session will overview the new KRAD data framework. Those who have been following the posts know this is a module we are very excited about. Learn about all the features this framework will provide, and the potential it has for bringing new data technologies into Kuali.

For Everyone

For those new and old to Rice, here are sessions that may be of interest.

Tuesday 2:00 PM - 2:45 PM

Tuesday 2:00 PM - 2:45 PM

Tuesday 3:15 PM - 4:00 PM

Tuesday 4:15 PM - 5:00 PM

Tuesday 4:15 PM - 5:00 PM

Wednesday 8:45 AM - 9:30 AM

Wednesday 1:15 PM - 2:00 PM

Wednesday 2:15 PM - 3:00 PM

This is the second session I will be co-presenting on. We will update you on all the new functionality that has been implemented in KRAD over the past year. Will include demos, and a look ahead to 2014 development efforts.

Thursday 8:45 AM - 9:30 AM

Thursday 8:45 AM - 9:30 AM

Thursday 11:00 AM - 11:45 AM

See the new data framework in action! In this session, you will see how the metadata abilities of the data framework can help you build KRAD views quickly.

Others of Interest (To Me)

Finally, for what it's worth, here are some other sessions I am most interested in. It goes without saying that there are many great sessions to attend, many of which I have seen in the past and greatly enjoyed. You might notice a theme in my selection for this year. I of course am interested in other efforts that relate to KRAD, and in general those concerning the future direction of Rice and Kuali.

 Wednesday 8:45 AM - 9:30 AM

Rice will be making the move to Git early next year. I am interested in learning what University of Arizona has learned from their migration.

Tuesday 9:45 AM - 11:15 AM

Tuesday 11:45 AM - 12:30 PM

Tuesday 2:00 PM - 2:45 PM

Wednesday 1:15 PM - 2:00 PM

Our direction for KRAD includes moving away from targeting portal deployments. Some of the work done so far includes building a standard application header for Kuali products, that includes application navigation and common workflow items. However, there is still a need for a 'launching pad'. IU is doing some great work in this area, which could serve as a basis for our KRAD implementation. Come to this session to learn more about what IU has done for their portal replacement.

Wednesday 1:15 PM - 2:00 PM

The bulk of my Kuali Days preparations has been for this session. You will see some of the early UXI design work, and its implementation in KRAD. There will be a demo of the KC proposal using the new look and feel, and using many new Bootstrap components.

For a full listing of sessions visit Also, make sure to grab one of the Rice brochures that will be available at the registration booth and many of the Rice sessions.

Hope everyone has a great time, and gain information that will useful for your own Kuali effort!

Jerry Neal
Kuali Rice KRAD Architect
Senior Developer, Indiana University

Friday, August 30, 2013

2.3 Baked, 2.4 In The Oven!

As of August 9th, 2013, Rice version 2.3 is now available to the public! This release includes several new features and improvements to KRAD. In this post, I will highlight some of these, and look ahead to the 2.4 release scheduled for early 2014.

Unified Header

Unified header gives you the ability to pack lots of useful information into your view header. You can combine the page text, add two more titles (area and support title), and provide view metadata.

Bookmarkable URLs and JS Back Button Support

Web requests/responses have changed greatly with the use of AJAX. We can now make frequent updates and requests on behalf of the user, even without their knowledge. This is a great thing, but one drawback is these requests occur without the browser's history tracking. In other words, the browser does not know how to rebuild the current state or allow the user to go back to a previous client state.

Thankfully, with HTML 5 History support we can give the browser the necessary information about our requests, so that the user may bookmark a certain point, or use the back button to go back to a previous point. Examples where this is used are page changes and dialogs (lightboxes).

Session Support

Kuali applications commonly maintain a lot of temporary state as the user interacts with the system. For example a user could be completing a document that contains several pages, or even use one screen for their entire workday. In order to free up shared resources, the user's state (or session) will be cleared after a configured period of inactivity. A user loosing thirty minutes (or more) of work is a very bad thing! Therefore features have been implemented in KRAD to help prevent the user from loosing data, and to gracefully handle a timeout when it does occur. These features include a session timeout warning dialog that allows the user to extend their session (shown below), configurable session timeout redirects, and a configurable timeout view.

Bootstrap, Less, and the Theme Builder

Version 2.3 comes with a new look and feel built with the Bootstrap library. This replaces the previous KRAD and legacy (KNS based) themes (look and feels). Along with this, a theme builder is provided that supports Less files, minification with versioning, and theme inheritance. For more information see Theme Blog Post.

Breadcrumbs and History

Like Breadcrumbs? If so, you'll very much like the new Breadcrumbs component. It is a complete rewrite of the previous component, and provides a huge amount of new functionality. Among this functionality is the ability to create 'sibling' breadcrumbs. These are items that appear under a breadcrumb item, and can be represented in a dropdown list or a suggest box (see screenshot below).

Breadcrumbs come in two flavors: location based and path based. Location based breadcrumbs serve as a site index. They tell you where you are at in terms of the application structure (e.g. 'Home -> Course Administration -> Edit Course 103'). The other flavor, path based breadcrumbs, show you where you came from. They give you the ability to navigate back to a view within a sequence of requests (e.g. 'Lookup A -> Lookup B -> Lookup C'). Applications can choose which type of Breadcrumbs works best for a particular view or context.

To support path based breadcrumbs, KRAD has also introduced the concept of 'flow'. Currently this is implemented using request parameters and controller methods (side note: down the road this could morph into declarative flow management, or possibly use of Spring Web Flow). Besides supporting path based breadcrumbs, the history manager also supports controller navigation actions (such as going back to the previous view).


Other notable 2.3 improvements include:

  • Dirty Fields - The third party dirty fields plugin has been dropped and replaced with a custom plugin. The previous plugin had several issues which are now resolved.
  • Row CSS - Adding custom CSS classes for table rows is now easier with use of map configuration. Classes can be specified by index, the 'even', 'odd' keywords, or even based on an EL expression that can check values for the current line.
  • Performance - As development approaches completion of KNS Equivalency and KRAD Phase 3 (functional requirements for Kuali applications), performance tuning is becoming a high priority. 2.3 improves the general runtime performance and also provides optimizations that can be taken advantage of in certain situations. Profiling shows reductions of up to 80% off the response time.


The release of 2.3 is significant not only due to the previously listed features, but also that it roughly marks the half way point to the 2.4 release. A good case can be made for 2.4 being the most important release of Rice so far. Without question, it will be the most important release for KRAD. Let's look ahead to the improvements and new features 2.4 will bring.

KNS Equivalency 

  If you have been following KRAD closely, you have likely heard the term 'KNS Equivalency'. This refers to the point at which KRAD will contain all the features provided by the KNS. This effort might be surprising given the number of features KRAD currently has. However, even though KRAD offers many more features and flexibility, there are certain places where the KNS provided an option or small feature not available in KRAD yet (or in many cases not provided at the same level of convenience). This effort will fill those gaps.
  In addition to feature completion, this effort includes developing a conversion guide and a set of conversion scripts. Our goal is to make the conversion effort as painless as possible for existing KNS applications.

KRAD Phase 3

  2.4 will continue Phase 3 development of KRAD. The main deliverables include:

  • Events - Simply put, this will bring the ability to generate client side events and client side updates declaratively in KRAD. Tools such as Angular JS are being looked at to provide the backbone for this functionality. We are really excited about this work! In fact, I will likely dedicate a post for describing this enhancement in the near future. It will be a killer feature!
  • Nested Views - Nested views will be our take on iframes, without all the problems inherent to iframe use. Currently in KRAD, only a single view can be rendered at one time. With this enhancement, multiple views can be rendered asynchronously (by nesting).
  Let's take an example. Suppose your application requires a shopping cart to be presented on each page. The shopping cart can be developed independently of other views (with its own view, form, controller, etc.). For views that should display the shopping cart, a simple group can be created that references the shopping cart view. On render of the parent view, an asynchronous call will be made to fetch the contents of the shopping cart, which will then be inserted into the appropriate DOM position. Very cool!
  • Accessibility - Phase 3 is also slated to include a second round of accessibility work using ARIA. Creating accessible table and tab structures, along with general cleanup for achieving WCAG 2.0 certification will be the priorities.
  • Keyboard Support - Keyboard support (beyond standard browser keyboard support) will be added in 2.4. Out of the box KRAD components (such as navigation) will be enriched with keyboard shortcuts. Applications will also be able to define enter key actions based on the user's location within a view. Finally, applications will be able to create custom shortcuts where desired.

JPA Support

The long awaited JPA support will arrive in 2.4. This includes not only JPA support, but also an overhauled data access layer that will setup KRAD applications for the future. Since Eric will be addressing this item in his posts, I will leave the details for him.


Could there be more? Actually, there is!

  • Performance - Performance work will continue in 2.4 (more accurately, there are plans for a 2.3 patch which will likely contain the remaining performance improvements). This will also include cleanup/optimization of the HTML output.
  • Security - KNS equivalency mandates a certain level of security be implemented. In addition, Kuali is taking a close look at security (developer training, tools, etc.) and discovered issues are being addressed in the software.
  • Tooling - KRAD tooling has not been top priority so far, but a lot of good work has occurred 'on the side'. Some of this will come to fruition for 2.4. This includes a custom schema for the UIF, along with support for Emmet. The new UXI project is also spinning up and will be contributing work to Rice. This is likely to include things such as the ability to build UIs outside of the normal Java development environment (for example, just with a standard text editor, this is another likely post in the near future!) and much more work with the KRAD Bootstrap theme, UI best practices, and accessibility.

  You can see why Rice 2.4 is a critical release for the Kuali projects and the community. This will end a three year cultivation of KRAD, and marks the start of the KNS conversion process. Forward Charge!

Saturday, June 29, 2013

Common Questions (aka Criticisms) About KRAD (P1)

As promised, in the next few posts I will answer some questions regarding the KRAD architecture. I have picked three questions we get the most, and that will also allow me to relay important principles of Kuali and the Rice project. These are:

  1. How is KRAD different from Java Server Faces (JSF)?
  2. Is KRAD tightly coupled with the data access layer?
  3. Why do I have to write all this XML? 

Before I answer these questions, you guessed it, a short history lesson! I pointed out in my introductory post that KRAD is a replacement for the Rice KNS (Kuali Nervous System) framework. However, KRAD retains many of the same goals as its predecessor. What were these goals? Well, there were many, but the major idea behind the KNS was to make it easier and quicker to build the Kuali Financial System, and then a bit later Kuali Coeus. In other words, it was geared for building large enterprise administrative applications. These are applications with many screens and which contain a lot of repetitive user interface content. While retaining this objective, KRAD expands to support student facing applications as well.

Another important factor in our decision making process is one of Kuali's core values: we are functionally, not technically, driven. What does that mean? Well, there has never been an official definition that I have heard, but to me it means this. First, requirements and priorities are set by functional committees. Second, those on the technical side should make decisions that meet those requirements, while minimizing delivery time and future maintenance costs.

Our situation on Rice though is very complicated. Recall, our first mission is to support the Kuali projects. However, we are a technical project. Furthermore, our second mission is to be a general development framework for use at higher ed institutions. This means we do attempt to stay as modern as possible with technology, pay back technical debt, and so forth (as evident by our current work on JPA support). However, even these work items go through functional approval and prioritization.

That should set the stage, so here we go!

How is KRAD different from Java Server Faces?

This is a great question and I am not surprised it gets asked often, for one simple reason: much of KRAD was designed based on Java Server Faces! So why do we not just use JSF? To answer this I need to describe the concept of components in KRAD. In functional terms a component is a reusable piece of UI content. There are basic components like text controls, buttons, and images. There are also more complex course grained components like tables, dialogs, and pages. Now, with JSF you can create much of the same UI content (text control, button, table, etc). So is KRAD meant to compete with JSF? No! KRAD is meant to build on top of tools like JSF.

Here is how it works technically. Producing HTML (and JavaScript) is the final goal, let us call this HTML markup level 1. JSF builds on HTML. Developers create JSF markup, and it in turn generates the HTML. So it is an abstraction, therefore let us call the JSF markup level 2. There are many other libraries like JSF that operate at level 2. For example, JSP, Velocity, FreeMarker, GWT, and various JavaScript libraries (I realize these tools are not really all the same, some do much more, but in general they all provide this HTML abstraction). Now KRAD builds another abstraction layer on these tools at level 2, creating a level 3. In other words, KRAD generates Freemarker/jQuery, which generates HTML. This abstraction layer in KRAD is provided by components.

This raises the question, why create the additional layer? There are many advantages to this architecture, and it has been interesting to see benefits come about we never planned for. Even though there are many advantages, I can summarize the main reasoning with two points.

The Spring Framework 

Rice is built using much of the Spring portfolio. To us, Spring is the best thing since sliced bread! We like it so much that we have expanded use of the Spring bean framework (also known as the Spring configuration system) to other areas besides dependency management. For example, the KRAD Data Dictionary uses the bean framework to configure metadata about application entities. Furthermore, the KNS used Spring beans for configuring some common screens (Lookup, Inquiry, and Maintenance). For KRAD, we wanted to use Spring beans for building all our user interfaces.

Why is this bean thing so great? It turns out the Spring bean framework is not just convenient and flexible for configuring service dependencies, but really any type of configuration. It has all the benefits of XML, with the power of Java inheritance. This provides a powerful environment for assembling pre-built components (see the next part) into a working user interface.

I realize this sounds a bit abstract (side note: I am noting this as a great topic for a future post). Let me give you one concrete way this approach benefits us.

Many readers have likely heard Kuali is "built by higher ed, for higher ed". Some people take this to mean the Kuali products have everything any higher ed institution will need, right out of the box. They simply install and go. This is not the case. Instead the out of the box products contain common functionality, as agreed upon by the higher ed partners. The rest is a customization effort by the institution (or commercial affiliate) implementing the product.

Now those who have attended a Kuali Days conference before have likely also heard the numerous vendor horror stories. The three complaints heard most often are:

  1. Vendor products are not built with the needs of higher ed in mind
  2. High licensing, support, and maintenance costs 
  3. Painful implementations and upgrades, where attempts are made to adjust the vendor product, so that it better fits the institution's needs

Kuali provides relief in all three of these areas. The first two are taken care of by the Kuali foundation and the criteria it sets for new Kuali projects (higher ed partners, community source). The third pain point is remedied by the design of the Kuali products. A great amount of effort is put into making sure institutions can make the customizations they need to, with minimal effort, and in a way that does not have a significant impact on upgrades. Much of this product flexibility is provided through the Rice framework itself, and the Spring framework makes this possible. This ability to easily make institutional modifications includes the user interfaces.

For example, if an institution calls an 'account' a 'fund', or their account number is 15 digits long instead of 7, no problem! They modify a few lines of XML and that change is reflected across the entire application. Need to add some fields to the travel section of the KFS disbursement voucher? No problem. A few lines of XML is all it takes. Furthermore, these changes are done entirely outside the core product, which means there is no need to reapply them each time an upgrade is made. Contrast this to what it would take for most products. First to even make a simple change like modifying label text, you would need to search through thousands of lines of markup, and likely make the change several times. Each time an upgrade is performed you would then need to reapply each of these changes again. This is a process that becomes unmanageable for more than a very small number of customizations.


Let us recall our history lesson and one of the primary goals of KRAD. Essentially this is to build enterprise web applications faster. How does a framework help us build software faster? One of the ways it can help is by pre-building functionality. Most applications have repetitive content, and certainly across multiple applications there exists a lot of repetitive content. We look for functionality like this and build it once, so that it does not have to be built multiple times by other Kuali developers.

In terms of building user interfaces, tools like JSF (level 2) certainly provide many useful features, but they are still fairly low level. That is, they require development to make a complete functional piece. In these tools you will not find a control that searches KIM (Kuali Identify Management) users. Nor will you find a header containing document information, or a fully functional notes and attachments tab. These are the sort of things that KRAD is meant to provide, again building off the lower level tools. Note you will also find lower level components in KRAD, which in some cases map almost one to one with the lower level tool. In fact, when new developers learn KRAD this is generally what they see first, which leads to questions like the one I am answering now.

Even in cases where KRAD provides a basic function (like a simple text control or button), there is still great value to the abstraction. This is because KRAD can encapsulate features such as UX best practices, accessibility, authorization, security, user preferences, theming, and mobile device support. These are not trivial matters in terms of development, and a great challenge to consistently implement without the use of a framework.

That explains why we are building this 'level 3', but now the question becomes why didn't we build on JSF? Well, the short answer is there were features of JSF we liked, but also features of the other 'level 2' tools we liked. As much as we would all enjoy being able to pick and choose features from different libraries, we had to pick one.

The initial functional requirements for KRAD (remember functionally driven) consisted of a list of roughly 20 'rich' UI features that were needed (as you might expect that list has grown greatly since then). Our mandate was not really to upgrade the Kuali tool set. However, we were using an old version of Struts (version 1), and really did not have any JavaScript library in place. Therefore adopting new tools was necessary to achieve the functionality in a way that would allow future growth (side note: this is a good example of how we can get technical issues addressed that likely would never get prioritized high enough by the functional groups). We performed extensive research on tools at that time (roughly 3 years ago, way before JavaScript MVC frameworks). Many of these met the requirements, had vibrant communities, and a promising future. The criteria then shifted to costs. What is the work involved to add the support in the framework, and then what will be the work involved for the existing Kuali applications to convert. The Spring/jQuery/JSP solution (now Spring/jQuery/FreeMarker) by far provided the lowest barrier.

Since that point we have basically been in heads down development and have not looked back (although there is now momentum gaining for looking into client side MVC frameworks). I hope this explains why we do not use JSF directly and why we chose to use other tools to build on. Now, developers who are familiar with both JSF and KRAD might be unsatisfied by this argument. They could say I have taken a narrow view here (looking at only the templating aspect), and there is much more to KRAD components and JSF, which contain duplication. For example, both have a lifecycle concept and similar component Ajax options. This is true. Unfortunately, with Spring/JSP we did not get any functionality like this and therefore built it ourselves (side note: I would really like Spring to add an abstract UI framework, like KRAD, to their portfolio someday). However, even though the concepts are similar, there are great differences in the implementations and the role they play within each framework.

In the interest of keeping this post from getting too long (and loosing your attention), I'll save questions two and three for the next post. Don't forgot to pass our blog along to others. It's the Kul thing to do!

Jerry Neal
Kuali Rice KRAD Architect
Senior Developer, Indiana University

Tuesday, May 14, 2013

Bootstrapped, Lessful Themes!

“We made the buttons on the screen look so good you’ll want to lick them.” Steve Jobs

Long gone are the days of building software that simply had to 'work'. Today's users want software that is easy to understand, efficient to use, and that looks great! Our foremost goal for KRAD is to be a platform for creating application interfaces that meet this criteria, and are pointed to by users as something they want to use. Fortunately there are many great libraries we can build upon for the "out of the box" KRAD look and feel. In this post I'll talk about the work currently going on in this area.

Before discussing the new work though, a bit about the previous look and feel efforts (this 'walk through history', or in some cases we might say 'trail of tears' is becoming a pattern for our posts!). Initially we created a look and feel that was based mostly on the Kuali Student application, and one that was based on the KNS (which we call 'legacy'). The reason for building the 'legacy' theme was so applications could begin converting screens to KRAD, and not have a drastic change in appearance from their old screens (and once everything was converted the application could then get a face lift). The majority of the CSS was custom, although the FSS (Fluid Skinning System) was included by default and used to apply some global styling. It should also be noted styling for many of the widgets comes from jQuery UI or the widget library itself, which presents a challenge for global theming.

There have been a few major iterations on the CSS over the past two years. The latest of these efforts implemented a global naming standard for classes (uif-*). Each component provided by KRAD is configured with a style class (regardless of whether any theme takes advantage of that class), then additional classes can be added when using the component. In addition, an approach was taken to 'stack' CSS classes based on the component hierarchy (an approach similar to what jQuery UI does). This class stacking reduces the amount of style duplication.

To summarize what is going on here, basically the structure of the page and the applied classes is defined within the UIF metadata (yes all that XML that everyone loves to hate). So where does the actual visual treatment come in? Well that is loosely coupled with the structure by an object we call the View Theme. The view theme is a simple object containing a list of CSS file paths, script file paths, and image paths. In order words it holds the configuration for our static web assets.

The theme concept allows applications to all be built with KRAD but not necessarily all look the same (as was the case with the KNS framework). This is evident by the applications that have been built with KRAD so far: Kuali Student, MyPlan, and KRMS all look vastly different. It will also allow for implementors to alter the look and feel as necessary without modifying any of the core application code.

While we have been busy doing this work, many other exciting tools have sprung up (sidenote: trying to build a framework that is 'modern' is like trying to have the latest gadget. Remember the commercial with the guy driving home excited by the new top of line M400 TV he just bought, and then sees a sign advertising the new M500 model?). One such tool is called Bootstrap ( There are many appealing features of the Bootstrap library, but what attracts us the most is the opportunity to offload the creation and maintenance of CSS, with a result that looks awesome.

Bootstrap makes use of another cutting-edge tool named Less ( Less is part of a class of tools (another is SaaS - that boost the standard CSS language with some new features, such as variables and mixins. Using these two tools, visual designers (or developers) will be able to construct great looking applications with much less effort.

To support these new tools we will be redesigning how our view themes work, which I will briefly overview now.

First, the ViewTheme object itself (this is the object that is configured in the UIF XML and associated with one or more views) will require just one property to be configured, the theme name. This can be any name you would like, but should correspond to a directory under the web root 'themes' folder (example '/themes/kcTheme'):

  <viewTheme name="kcTheme"/>

From here the remaining necessary configuration will be derived by convention.

There is one other thing we need to do though, and that is prepare our theme for consumption. This will involve two, possibly three steps:

  1. Overlay assets from a parent theme (optional)
  2. Compile .less files to .css
  3. Build minified .css and .js

This work will be performed through the maven build process. A custom plug-in will do the work of overlaying, compiling the Less files, and building the minified files. In short, the functionality will be similar to the Asset Pipeline offered in rails (later on we could add support for such things as CoffeeScript as well).

Let's take a couple of examples to make this concept more clear. First, we'll create a completely new theme (meaning we will not reuse any files from an existing theme). Assume our theme directory is '/themes/kcTheme' (corresponding to the view theme configuration above), and has the following contents:

A real KRAD theme is likely to have many more files, but this will do for our example. You might be wondering the purpose of ''. This will hold the compile values for all the Less variables. After the build runs, our theme directory will contain the following two files (note the previously listed files will still be in the directory as well):


The kcTheme.min.css and kcTheme.min.js resources will then be linked to the view in a test or production instance. Notice the version tag added to each minified file. This ensures when a new version of an application is released, users automatically download the updated resources. In development mode, the individual files (less, css, js) will be linked to the view for debugging.

Now here's the cool part! Instead of creating a theme from scratch, we can inherit from another theme (for example extending the out of the box KRAD theme). Suppose now our theme directory simply contains:

And the first line of contains 'parent=kcTheme'. This indicates which theme to inherit from. In this case we want to inherit from 'kcTheme'. The file from this directory will override the file from the inherited theme. If the original theme makes good use of variables (as the out of the box theme will), the actual styles (colors, fonts, padding) can be altered in this way.

We can also add files to the inherited theme, or override any file from the original theme (including images) by including a file with the same name:

This would override the 'layouts.less' file and 'logo.png' image from the inherited theme, along with adding the asset 'additionalStyles.css'.

Finally, since really the theme is created from the final directory contents, we can take advantage of WAR overlays to customize an out of the box theme without creating a new theme. For example, to modify the content for the out of the box KRAD theme, we create the folder '/themes/krad' in our web project and then place any of the files we wish to override.

For those of you ready to beautify, lessify, and simplify your themes, the work should be completed for the Rice 2.3 release.

Next time I will discuss a variety of topics, as I take on 'Top Questions (aka Criticisms) Regarding KRAD'.

Sunday, May 5, 2013

Data, Data Everywhere

Simplify, Encapsulate, Don't Repeat Yourself (DRY)

This is the mantra for the work that the Rice team is doing on the new KRAD data architecture. It's a sweeping project with the end-goal being support for the Java Persistence API (JPA) within Kuali. I'm really excited to tell you all about what we're up to. But first, to ensure that you have all of the context, I want to take a little trip down memory lane...

By all accounts, the early days of Kuali were very exciting. The unprecedented goal of bringing universities together to collaborate on the creation of an enterprise open source financial system for higher education was certainly groundbreaking. To kickstart the technical work, a number of developers and architects got together to design and define the architecture for Kuali. Coming out of this initial flurry of activity was the decision to use the following technologies for development of the software:
  1. Java
  2. Spring Framework
  3. Apache Struts
  4. Apache ObJectRelationalBridge (OJB)
  5. Oracle and MySQL databases
Now, I'm sad to say that I wasn't involved in Kuali at this early stage (in fact I probably wasn't even working at Indiana University yet), so hopefully I'm not misstating the above. Regardless, the Kuali Nervous System (KNS) which was part of the first release of Kuali Financials certainly incorporated all of these.

Many of you may know that KRAD is the heir-apparent to the KNS and has replaced Apache Struts with Spring MVC, effectively expanding our use of the Spring framework. But what I'd like to spend some time talking about is the Apache ObJectRelationalBridge.

For those who don't know what OJB is, it's the object-relational mapping library that Kuali uses. It takes Java objects and the data represented therein and "saves" it to tables and columns in a relational database. It also loads data from the database back into Java objects so that the application can work with it. This is pretty typical object-relational mapping (ORM) functionality.

At the time that the early technology decisions were being made for Kuali (2005-ish), there was another popular Java ORM that a lot of people were using. It was called Hibernate. So why did Kuali decide to use OJB and not Hibernate? I honestly can't say for sure since I wasn't involved in those conversations, but I suspect it had to do with the fact that OJB worked well, had good documentation, and was being used widely by a number of the technologists who were involved in those early decisions. There was no clear winner at the time, as it was relatively early in the history of Hibernate as well. So the Kuali project decided to go with OJB as the ORM and persistence technology of choice.

I think it's safe to say that we bet on the wrong horse.

Since that time, Hibernate was folded under JBoss, grew by leaps and bounds in popularity, and became the de facto standard for persistence in Java. OJB was abandoned by it's creators and is now dead. I mean really dead. So dead in fact that Apache moved it to a special place called the "Attic" in 2011.

OJB still works and works well, but it is no longer maintained and it does not make sense for Kuali to continue to use it at the core of our applications. This is not a new revelation by any means, we've all been aware of this for quite some time. In fact early efforts to migrate away from OJB began all the way back in 2008!

The funny thing is, getting rid of OJB has turned out to be harder than it should be.

Why is that? Well, I think it comes down to a couple of things:
  1. The semantics that Apache OJB used for things like lazy loading is totally different from products like Hibernate.
  2. There was a lot of special logic built into the KNS in Kuali which was tied to the semantics and behavior of OJB. Untangling this and providing a clear upgrade path for existing applications is not a trivial exercise.
These are not insurmountable obstacles, but they certainly require us to take a careful approach as we look toward sunsetting support for OJB within the Kuali technology stack. A renewed sense of urgency and vigor around this problem manifested itself when Apache announced that they were moving OJB into the Attic in 2011. However, the reality remains that we have a number of very large Kuali applications which have spent years developing on top of OJB.

This brings me to the fun stuff.

Near the end of this year, Kuali Rice version 2.4 is scheduled to be released. A little feature called "JPA Support" has top billing for that release. JPA stands for "Java Persistence API" and defines a standard for persistence in Java. There are multiple ORM's which have support for JPA, including Hibernate, EclipseLink, OpenJPA, and others.

However, recognizing the fact that years and years of code have been developed within Kuali Rice which depend on OJB, there is an awful lot of technical debt to pay down as things have been tacked on and hacked in over the years. Accordingly, we are taking a holistic approach to solving this problem through a refactoring and redesign of the way that KRAD interfaces with data. We are implementing this in a new module called krad-data.

I'm sure there are a number of people reading this who have spent hours upon hours building or modifying Kuali applications using the KNS. To those people, I just want to say this:

I think you are in for a treat.

Have you ever spent hours modifying XML data dictionary files and wondering why in the world you have to type in an attribute definition for every single property on your business object? Have you ever wondered why all of your business objects have to extend from a common base class and can't just be simple POJO's? Have you ever been annoyed by the fact that you have to provide labels and sizes for everything? Have you ever wondered why the heck you have to manually define validation patterns when the framework should be able to just figure it out? Have you ever had the need to interface with the database using plain-old JDBC? Or maybe using one of those fancy new NoSQL databases?

Lastly, have you ever wondered why you need to have novels worth of XML in data dictionary files in your project at all? I mean, shouldn't the framework be able to figure out most things from all the hard work you did to construct the objects in Java, map them to the database using your ORM, and define the tables, columns, sizes, and constraints within the database? Nobody likes to repeat themselves.

If you answered yes to any of the questions above, then I think you are going to like what we have in store for you.

Suffice it to say that we are not just "adding support for JPA". We are improving the way that Kuali applications can access and work with data. We are also going to great pains to simplify the APIs in Kuali Rice which handle data persistence and metadata. We want to make it easy for developers to use KRAD to build their data-driven applications. Nowadays, people expect this from the rapid application development frameworks that they use. If that wasn't the case, then frameworks like Ruby on Rails wouldn't be as popular as they are. There is no reason that KRAD and the toolset we use in Kuali can't be just as powerful, or even more so.

Here is a list of features that krad-data will have (in no particular order):
  • Built-in support for JPA.
  • Simplified API for handling typical CRUD operations and accessing metadata.
  • Pluggable metadata pipeline for loading and merging metadata from various sources, including:
    • database
    • ORM
    • annotations
    • reflection
    • and the old fallback of XML data dictionary files (note that these become optional!)
  • Support for "natural language" defaults on things like labels.
  • Convention-based defaults for UIF controls based on data types.
  • Data formatting using features built into Spring.
  • Ability to use POJO's for your data objects. 
  • Flexible data types to allow for dynamic data objects which may not be easily representable as static Java types at compilation-time.
  • A simplified "Extension Framework" which requires no manual ORM mapping (or re-mapping).
  • Data validation support built into the persistence API, including support for JSR-303 bean validation (hopefully, if we have time).
  • A service provider interface (SPI) for plugging in any type of data store for persistence for a given type of data object. This could include:
    • JDBC
    • Web Service-backed persistence
    • Alternate frameworks like spring-data
    • Various types of NoSQL data stores
  • The above should be able to eliminate the need for a special "Externalizable Business Object" framework.
We are also planning to do all of this work without breaking any legacy KNS or KRAD applications which are using the existing data layer and OJB support. This is no small task really, but we feel it is important that people will be able to upgrade to 2.4 without breaking existing application functionality, because this will facilitate a "phased" migration for those applications. This includes the ability run both krad-data and the "legacy" OJB-based data layer along side one another.

Furthermore, I should say that much of the krad-data module has already been completed on the branch we've been using to do the development. We still have a lot of work to do to finish hooking things back into the rest of KRAD and testing it to make sure it all works, but things have been progressing well thanks to the hard work of the small but talented team of developers that is working on this effort.

In my next post, I'll talk about the design and architecture of krad-data and dive into some of these features in a bit more depth. Stay tuned!