OGNL is the Object Graph Navigation Language - see http://www.ognl.org for the full documentation of OGNL. In this document we will only show the additional language features that are provided on top of the base OGNL EL. XWork-specific Language FeaturesThe ValueStackThe biggest addition that XWork provides on top of OGNL is the support for the ValueStack. While OGNL operates under the assumption there is only one "root", XWork's ValueStack concept requires there be many "roots". For example, suppose we are using standard OGNL (not using XWork) and there are two objects in the OgnlContext map: "foo" -> foo and "bar" -> bar and that the foo object is also configured to be the single root object. The following code illustrates how OGNL deals with these three situations: #foo.blah // returns foo.getBlah() #bar.blah // returns bar.getBlah() blah // returns foo.getBlah() because foo is the root What this means is that OGNL allows many objects in the context, but unless the object you are trying to access is the root, it must be prepended with a namespaces such as @bar. XWork, however, is a little different... In XWork, the entire ValueStack is the root object in the context. But rather than having your expressions get the object you want from the stack and then get properties from that (ie: peek().blah), XWork has a special OGNL PropertyAccessor that will automatically look at the all entries in the stack (from the top down) until it finds an object with the property you are looking for. For example, suppose the stack contains two objects: Animal and Person. Both objects have a "name" property, Animal has a "species" property, and Person has a "salary" property. Animal is on the top of the stack, and Person is below it. The follow code fragments help you get an idea of what is going on here: species // call to animal.getSpecies() salary // call to person.getSalary() name // call to animal.getName() because animal is on the top In the last example, there was a tie and so the animal's name was returned. Usually this is the desired effect, but sometimes you want the property of a lower-level object. To do this, XWork has added support for indexes on the ValueStack. All you have to do is: \[0\].name // call to animal.getName() \[1\].name // call to person.getName() Note that the ValueStack is essentially a List. Calling [1] on the stack returns a sub-stack beginning with the element at index 1. It's only when you call methods on the stack that your actual objects will be called. Said another way, let's say I have a ValueStack that consists of a model and an action ([ model, action ]). Here's how the following OGNL expressions would resolve: \[0\] // a CompoundRoot object that contains our stack, \[model, action\] \[1\] // another CompoundRoot that contains only \[action\] \[0\].toString() // calls toString() on the first object in the ValueStack // (excluding the CompoundRoot) that supports the toString() method \[1\].foo // call getFoo() on the first object in the ValueStack starting from action // (excluding the CompoundRoot) that supports a getFoo() method Accessing static propertiesOGNL supports accessing static properties as well as static methods. As the OGNL docs point out, you can explicetly call statics by doing the following: @some.package.ClassName@FOO_PROPERTY @some.package.ClassName@someMethod() However, XWork allows you to avoid having to specify the full package name and call static properties and methods of your action classes using the "vs" (short for ValueStack) prefix: @vs@FOO_PROPERTY @vs@someMethod() @vs1@FOO_PROPERTY @vs1@someMethod() @vs2@BAR_PROPERTY @vs2@someOtherMethod() The important thing to note here is that if the class name you specify is just "vs", the class for the object on the top of the stack is used. If you specify a number after the "vs" string, an object's class deeper in the stack is used instead. The top keywordXWork also adds a new keyword – top – that can be used to access to first object in the ValueStack. |