This stuff has pretty much been implemented by the json-viewer (as an implementation of Restful Objects spec)

WTH

This page isn't any reference for anything. It's just my notebook for ideas.

I've started to flesh out my ideas on this topic into a JSON RESTful protocol: see this page for details. – Dan

What

The idea is to develop viewer agnostic protocol to communicate with the Isis runtime.

Why

Currently every viewer code (html, dnd etc.) is interacting with Isis directly by calling methods. One problem is that every viewer developer must be familiar with Isis' metamodel API. However, this API is not any clear for complete beginner; like any moderately complex API there are some pitfalls (and probably some flaws too, if truth be told).

But that's not the main problem. As far as I can tell every viewer has it's own wrapper around NOS API. That's the main problem. Every new viewer developer will eventually develop his own wrapper. It's not hard when you are doing something inside JVM but turns into really challenging task when you are trying to create something outside e.g. GWT viewer.

What about the restful-viewer?

The restful viewer is a potential starting point for this protocol. It already exposes the domain model using REST, providing XHTML representations of domain objects and links to their state.

One possibility is to implement the protocol by providing an alternative, lightweight JSON representation.

Statements

  • protocol must be textual
    • application/json is the best choice
    • plugin style implementation, so fans could implement their own application/xhtml or binary plugins
    • lightweight as possible, avoid sending huge amount of data
  • protocol must be complete
    • no language specific parts (server/viewer could be implemented in different languages)
    • no platform/country depended structures
  • async interaction: request/response model
    • viewer should use async request/response model with restriction that any request could be rejected (e.g. two consecutive requests where the first invalidates the second: delete object & update object - as can't update already deleted object)
      • (I know that we don't have async support now, just leave it now as is)
    • server should keep queue of requests and execute them one-by-one in order or receiving
  • context manager
    • not sure exactly what this bullet means; the restful-viewer aims to be stateless so maintaining "context" is expected to be the role of the client. But see also discussion on auth (below).
    • we couldn't trust the client to maintain the context, but probably we mean different things here (Alexander)
    • some clients just can't hold the context as they don't have java virtual machine

Questions

  • How should we send data?
    • Specification + object + state. Viewer must construct view for specification, fill it with object data and adjust state status.
      • pros: spec must be send only once, viewer know the full object specification
      • cons: viewer could access hidden property values and compromise Isis rules enforcement
    • Current snapshot. We send object as it currently visible.
      • pros: easy to implement, no information leaks
      • cons: every object update forces viewer to repaint object

The restful-viewer is the latter. However, there are separate resources for an object's properties vs. its collections http://incubator.apache.org/isis/viewer/restful/index.html so is relatively fine-grained.

  • What kind of services every viewer gonna need?
    • auth
    • invoke any action (object, service)
    • load/update object
    • fetch Isis runtime updates (infos, warnings)

All of these except the last (runtime updates) is supported by the restful-viewer. In terms of authentication the viewer has a hook to allow user credentials to be picked up from "wherever", eg the client might send a cookie, or there could be some industry standard to integrate with.

Links

Check this for user stories https://cwiki.apache.org/confluence/display/ISIS/UserStoriesForWritingAViewer

  • No labels