This viewlet was provided to help you write an Ajax user interface. Of course, it does not solve the whole problem ofÂ creatingÂ a modern browser experience which includes visually rendering objects in a browser window, and synchronizing them with the server running Infogrid. However it does kick-start the process and is one less issue to deal with.
There is already support for Json in the tree, from a Viewlet in the ig-ui MeshWorld test apps. called ObjectSetViewlet.jsp. As its name suggests it is a java server page implementation. It’s packaged conventionally in the web tree in v/viewlet/objectset/ObjectSetViewlet/text/json so that it can be dispatched when you provide a mime type of “text/json” in the lid-format parameter of the request URL. As its name suggests it’s dispatched on a collection of objects returned by traversing from the object identified in the request URL – e.g.Â http://localhost:8084/org.infogrid.meshworld.net/nnnnn?lid-format=viewlet:org.infogrid.jee.viewlet.objectset.ObjectSetViewlet&lid-format=mime:text/json&lid-traversal=org.foo.Test/Entity_Collects_AnotherEntity-S
This serves as a useful example for how to develop your own Json viewlets, however you could soon end up with several special purpose jsp viewlets that could say render the specific object in the request as Json,Â renderÂ it with and without its metaÂ informationÂ and so on … These different rendering requirements are based on how you intend to use the objects into which the Json response getsÂ transformedÂ when it’s evaluated in the browser.
So it seemed like a better idea to provide a universal viewlet that could fulfill all these requirements by being passed URL arguments to control its behavior. It works by performing aÂ transitiveÂ closure on the object graph from the object specified in the URL – without looping. Whenever a cycle is detected it writes the object’s “id” Â but not its contents, to stub the graph so that the client has a reference it can deal with later.
UnlessÂ constrainedÂ by the arguments, its default behavior is to dump everythingÂ about every object that is encountered in the traversal. So be warned – if you have a very interconnected graph you could end up dumping the whole contests of your meshbase.
The JsonViewlet takes the URL arguments:
- level=n|0 – 0 means no limit and will follow every relationship
- dateenc=func|string – determines how Date is rendered, either as a function or String
- ignoreblessing=entitytype_name_regex – names of blessings to beÂ ignored
- meta=[no|false]|[true|yes]|only – whether or not to dump meta information
- trimsa=[yes|true]|[no|false] – trims the subject area name from the property names
Bold = default.
Ignoreblessing, has the effect of not dumping the values of the specified blessing. This isÂ primarilyÂ usefulÂ for removing the Probe model properties which bless probed entities. This is controlÂ informationÂ that isÂ probablyÂ not needed by a client – unless you are say writing a probe manager. You can pass it a regularÂ expressionÂ or the fully qualified class name, and theÂ argumentÂ can be repeated or comma-delimitedÂ to specify as many of these as you like.
Finally there is trmsa – whichÂ simplyÂ trims the subject area nameÂ off the front of property type names. These strings can get a bit long and often they are not needed if you’ve specified the property type name uniquely.
There is some error checking of these arguments, and if any error is encountered a Json error is returned as an “id” and “msg.” There should be no other errors returned.
Json returnsÂ valuesÂ asÂ eitherÂ numbers or strings, therefore blobs are treated as references and returned as URL’s that reference the specific property, and request the PropertyViewlet do the rendering.
In order to use this viewlet you’ll need to make sure it’s added to the application’s viewlet factory, using something like this:
So please give it a try. It would be nice to build out more components needed to build a rich client experience.