I (Adrian Blakey) got signed up to speak about Infogrid at the San Francisco Java User Group. As of this morning it looks like the event had 162 171 people signed up.

I’ll borrow Johannes slides for the talk, and give a simple demo using a database of National Provider Identifiers to show off probes and listeners. Please come up to me at the meeting and say hi, I am sure there will be much that I either don’t cover or quite frankly do not understand well enough about IG to give it its due.

Conrad Irvin has a nice post on how to fix some of the problems with the ubiquitous MVC (“Model View Controller”) architecture that’s used in so many user interface frameworks, from rich clients to web apps.

He calls the model MOVE, i.e Models, Operations, Views and Events: his Models capture the information in the application, Views render it and, when the user interacts with a View, raise Events that are received by Operations that modify the Model.

In InfoGrid, we obviously use the word model more precisely by distinguishing what we call a model (the schema) and the graph of objects (the data) — together what he calls the Model.

Where it’s getting interesting is Operations and Events: since the InfoGrid HttpShell has been supporting HttpShellHandlers, these handlers are almost exactly what he describes as operations. We can think of the symbolic names of handlers as used in a JSP page as the Events in his model, and the binding of symbolic names to handlers as the mapping between Events and Operations.

So we like his description of an improved MVC model, and offer an example where it has been implemented.

Split AclBasedSecurity into two: an ACL-based AccessManager implementation that does not rely on Guards, and an AccessManager implementation that evaluates Guards but is independent on a particular model (such as the AclBasedSecurity model)

Eliminated org.infogrid.model.AclBasedSecurity, and instead introduced org.infogrid.meshbase.security.aclbased, which also includes a model

DelegatingAccessManager now supports delegating to multiple other AccessManagers, all of which must agree

added ThreadIdentityManager.suExec

When there isn’t a ProtectionDomain, it’s free for all in AclBasedAccessManager

moved org.infogrid.model.SecurityTest into the attic; currently not used

pass SaneUrl through to ViewletFactory, so it can access request attributes

created org.infogrid.jee.security.aclbased tag library for AclBasedSecurity Subject Area

added TextStructuredResponseSection.containsContent

replaced ViewletAlternativesTag.js with more general-purpose ToggleCssClass.js

support redirect to newly created object in HttpShell

Created BracketTags, which allow conditional generation of, say, <ul> and </ul> tags depending on whether or not the content tag has any non-whitespace content.

factored out AbstractSaneRequest.urlWithoutMatchingArguments for easier reusability

trim entered identifiers before trying to resolve them in HttpShellFilter

Better error reporting for HttpShell

IncludeViewletTag more robust if path not specified

Removed the List<Throwable> in request attribute for collecting processing exceptions; now abstracted into new interface ProblemReporter

Allow null identifiers for create access verb in HttpShell again

hyperlink on UnsafePostException’s message

TitleTag to use a separate section in the StructuredResponse

default mechanism for TitleTag with Viewlet name and app name, can be overridden with TitleTag

<tmpl:title> tag prints <title> tags itself

fixed userVisibleName on Viewlet

JeeViewlets’ default POST URL used to sometimes leave out reached MeshObjects, which would list all found-by-traversal MeshObjects after post, which was very confusing. Removed traversal spec in case there are no reached MeshObjects

A new viewlet was recently added to the build called JsonViwelet that renders a graph of objects in Javascript ObjectÂ NotationÂ (Json). It’s packaged in a new module called org.infogrid.jee.viewlet.json to isolate its dependency on “Jackson” – an open source Json parser, from the rest of the ig-ui modules, which is checked in to the ig-vendors package.

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

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.

Level, determines the depth of the traversal. Since the object identifiers areÂ returnedÂ for the next lower level you could provide code in your javascript client to later makeÂ anotherÂ call to return the next levels in the graph.

Dateenc, controls how IG TimeStamp’s are rendered in json. Json does not provide a way to encode dates, so there is a choice to do thisÂ eitherÂ as a string or as a javascript DateÂ constructorÂ method signature. They both work – you choose.

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.

Meta, gives you the option ofÂ eitherÂ supressing the metaÂ informationÂ or only dumping the meta information about an object. Javascript is a typeless language andÂ probablyÂ does not care too much about the metaÂ information. However there are some client frameworks that are wrestling with the issue of java-javascript mapping andÂ doingÂ thingsÂ like simulating fixed class hierarchies – so maybe the metaÂ informationÂ might beÂ important.

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:

Alex Popescu argues that document databases have an impedance mismatch with object-based software. He compares the situation to relational databases:

“One of the most often mentioned issues reported by software engineers working with relational databases from object-oriented languages is the object-relational impedance mismatch. Document databases adopters are saying that one benefit of document stores is that there is no impedance mismatch between the object and document worlds.

“I donâ€™t think this is entirely true.”

Given that databases and in-memory representations of objects serve different purposes, I don’t think we’ll ever completely manage to do without mappers of some kind. (Otherwise we’d all be using Java Object Serialization as our database.)

However, to me at least it appears that of all database technologies, graph databases like InfoGrid have the smallest impedance mismatch: a graph of objects is fundamentally closer to what is happening in memory of an object-based application than any other representation (e.g. document-based / hierarchical / relational / key-value etc.)

Educative practices are items or reasons which derive from observations and thinking. These hypotheses are actually attempted and proved by proponents mainly because the generic ideas that help to explain and calculate comprehension. A United States pedagogue recognised via the company name David Botkin displayed the definition of revolutionary instruction for the technological network 2 decades returning. Botkin acquired a number of these answers brimming with controversies since expression meant permanent and finished revision to the policies which traditional notions on instruction regarded as axiomatic, (Lee and Performed 2007, 194-204). Appearance David Botkins resourceful teaching takes into account awareness less an end but as a technique, orienting with the kids style progression. His check out is in opposition to classic training which landscapes the foremost value of the entire process of training as know-how truly being transferred to the student. The useful schooling offer does not put emphasis on taking care of the procedure of knowledge, for this reason establishing scenarios the spot that the learner is at a best place to produce his very own aims and work at achieving them, changing themself and regulating the educational undertaking. The common variety of knowledge has a composition that is fewer stable and is not going to put into action the required evolves as time shifts. Insight accumulation earnings as traditional in subjects like literature and reputation, which might be broadening and growing gradually unlike science things like math, biochemistry and science that can be tricky to adjustment for quit some time.

Can i have a need to acquire a seating assignment? Style airline companies promote movement project component make it possible for web pages

Botkin, during his research into the useful plan, gives you another differing final choice which implies that the device of education and learning is powerful characterised based on the altering composition that is definitely habitually undergoing regrouping and renewal with new educational curricula and disciplines truly being launched on a regular basis, (Botkin, Jim and Kaipa 2004, 409-423). (more…)

InfoGrid trunk has been upgraded to NetBeans7, but for the time being, we remain with Tomcat6. Unfortunately the NetBeans guys have not exactly made it easy to remain compiling JSPs against the Tomcat6-supported specs instead of Glassfish.

In the relevant InfoGrid projects, we set the relevant properties in project.properties for Tomcat6. They are picked up when running the build from the command line.

If you find yourself with compilation errors when compiling from the IDE, the following trick might help:

The recent workshop on Graph Databases in Barcelona sparked an interesting debate among vendors of graph databases about how to accelerate graph database adoption.

I don’t think that debate has been resolved yet. Perhaps this post will help a bit.

Some opinions that I heard were:

there are significant differences between the various graph database products on the market (e.g. graphs, property graphs, properties on edges or not, hypergraphs etc.). Unless they are more similar, customers will fear lock-in and not buy any of them. Here is a variation:

relational databases only took off once there was agreement on the SQL standard among vendors. We need to cooperate to create a similar language, otherwise graph database adoption will not take off either.

most potential users of graph databases have never heard of them. How could they use any if they don’t know they exist?

even if possible users know of graph databases, they do not know what the use cases are because use cases and success stories have not broadly been documented.

What do you think the biggest obstacles are for graph database adoption?

The result is a set of nested HTML definition lists, which are a good match for an outline in HTML.

By way of explanation of this example, the outer tag is a big loop, which iterates over all elements in the outline. Every time we walk down the tree, the <tree:down> tag fires and emits the HTML list start element contained there. Every time we walk up the tree, the corresponding <tree:up> tag triggers and closes the list. “Subject” is the name of the start node as JSP bean, and the xpath-like expression is used to describe which branches to traverse in the graph, because it would just as simple traversing the opposite direction, or sideways.

I don’t think it gets much simpler Imagine the pain in SQL, particularly if the tree is deep …

Here’s an example. Let’s say on your web page, you want to show a list of nodes related to some node ‘x’. For example, a social media friends list, or list of purchases, or bookmarks etc. Here is the JSP code:

If you look closely, you see that not only does it print the neighbor nodes in the graph, but also adds a hyperlink to them, so they can clicked on and examined. And if there are no neighbors, a message is printed saying so.

What if I don’t want any kind of neighbor, but only those related in some fashion, say business colleagues? Well, depends a bit on your model, but it’s usually as simple as replacing the first line of JSP above with something like this:

Notice that there is no other code that needs to be written, no object-relational mapping, no SQL syntax to get right, no handler code or other clumsy magic. Of course, you can have may of these statements on the same page, nested etc.