Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Supporting OGNL in Tag Libraries

Adding support for JSTL's Expression Language was fairly easy to do in the Display Tag. It was as simple as adding an ExpressionEvaluator and subclassing the ColumnTag and the TableTag. From there, all that was needed was needed a new TLD to reference these new classes.

So the question is - would it be just as easy to support the OGNL Expression Language? Does it have an ExpressionEvaluator I can write with the same simplicity as the JSTL version? If I could figure that out, I think creating OGNL-aware versions of the displaytag and struts-menu would be a piece of cake. All you'd need to do would be to change you're TLD's URI and you'd be off to the races!

Posted in Java at Feb 25 2004, 10:43:08 AM MST 3 Comments
Comments:

Try ognl.OgnlRuntime... It lets you evaluate an expression...

Posted by Jason Carreira on February 25, 2004 at 07:04 PM MST #

!Or you could play with using Groovy as the expression language inside the display tag :) [{Java2HtmlPlugin GroovyShell shell = new GroovyShell() shell.setVariable("pageContext", pageContext) shell.setVariable("bean", whatever) ... result = shell.evaluate("user.name") result = shell.evaluate("bean.findCustomers().findAll { it.location == 'US' && it.orders.amount > 1000}") }]

Posted by James Strachan on February 26, 2004 at 12:16 AM MST #

There are a couple of way to execute an OGNL expression, depending on how much information you want to cache for efficiency. Also OGNL supports "get" and "set" operations; as such OGNL is a binding language rather than just an expression language. Of course it also serves admirably as an expression language for the purpose to which you are putting it.

The simplest way is to use the ognl.Ognl class to evaluate the expression against a root object:

    ognl.Ognl.getValue("user.name", rootObject)
    ognl.Ognl.getValue("bean.findCustomers().{? location == \"US\" && orders.amount > 1000 }", rootObject);

This will parse then evaluate the expression against the given root object.

For greater efficiency you can pre-compile the expression using the parseExpression() method:

    Object expression = ognl.Ognl.parseExpression("user.name");
    ognl.Ognl.getValue(expression, rootObject);

For repeated evaluations (such as you might have in a JSP tag that evaluates many times), you definitely want to cache the parsed expression. For your immediate purposes this will be a good test of how well it works within your framework.

This is just the simplest way of using OGNL. There is also a "context" object that allows you to put variable values in scope, and also track the current state of the expression evaluation.

There are many extension points that allow you to control how values are extracted from objects that you will definitely want to investigate:

  • Class resolvers allow custom class resolution. Sometimes (especially in webapps) the normal Class.forName() does not suffice.
  • Property Accessors allow you to extend the notion of properties to other domains than JavaBeans. A good example of this is a property accessor for the servlet classes that support the setAttribute()/getAttribute() pattern. Session, context, etc. attributes can be accessed simply by referring to property (i.e. "session.foo" will call HttpSession.getAttribute("foo") instead of looking for a getFoo() method).
  • Elements accessors control how objects are iterated. The default elements accessors provide iteration over standard collections classes, native arrays, etc. There is also an Elements accessor for numbers that will produce sequences. Custom elements accessors allow you to produce iterations from things that normally are not iteratable (like the numeric accessor).
  • Type converters allow you to customize how objects are converted to other types in method calls and return values. Back to the servlet example you often face conversion from String to other objects during form post binding. The default type converter will convert between numeric types and to/from String and numeric types.
  • Null handlers allow you to customize how null return values and null properties are handled, giving you an opportunity to intercept these null values and replace them with other objects at runtime.
  • Method accessors are not used very often, but they allow you customize the way methods are called.
  • Member access allows you to inject accessibility code in controlled circumstances so that you can lower normal Java protection for certain cases. This is useful, for example, when writing code that does serialization and needs to reach into classes to retrieve private members. The default OGNL class for this does nothing, so normal Java rules apply.

Please feel free to ask any further questions you have to either me or the OGNL mailing list (see http://www.ognl.org for details)

Posted by Drew Davidson on February 27, 2004 at 10:33 AM MST #

Post a Comment:
  • HTML Syntax: Allowed