On 13 August 2012 18:26, Barry Woods <[email protected]> wrote:
> > I have been working on a custom JQuery based client viewer implementation > of > the Restful Objects viewer. This is partly based on the work Adam Howard > has > done in his AROW implementation but adds specific use cases using Mustache > templates. > > Excellent to hear. Do you intend to open source this, can I ask? > > I have made good progress but I am now working with some more complex > domain > objects and run into some issues with the JSON Viewer (v0.2.0- incubating). > These issues occur when attempting to persist a new object. > > > > > 1. The objects have a number of properties that return derived values > and hence only have a getter but the viewer is not catering for this > scenario.. When attempting to persist a NullPointerException is raised. > This > is caused by an attempt to execute the clearPropety method on a null > PropertyClearFacet. > > 2. There are also some properties that are annotated as optional, but > again a NullPointerException is raised if any of those properties are > omitted. This would seem to break the Restful intent to allow independent > development of client and server since the client would need to be aware of > and supply a value for every new property added to domain objects. > > Are you aware of any of the issues raised in 1 and 2 that are perhaps > addressed in a later version or a bug report? > > I can't tell you without digging into the code whether these issues are fixed in trunk; I know that Adam was working from trunk rather than the 0.2.0-incubating release. I will be returning to the RO viewer when time allows, but in the meantime you have two options: a. fix up the code yourself. I'm currently mirroring SVN to github [1]. You could fork this and make the changes, then submit a pull request back to me. b. do what Adam did and work against the RO.Net impl, which is complete against the 1.0.0 release. I'm sure Richard will be happy to oblige. > 3. Finally a more complex issue and which may be related to an > inappropriate strategy for a Restful implementation but one that worked > well > with the DnD and HTML viewers. > > I have a graph of nodes in the domain and the relationships between nodes > are described by a LinkObject representing the node edges. A contributed > action is invoked on a parent node and a transient instance of a new child > node is returned. > > Hitherto a transient link object has also been created during this invoke > which contains the parent node reference and other properties set according > to context. A reference to the transient link object (annotated > @NotPersisted, @Optional and @Hidden) is set in the new transient child > node. The link object is subsequently persisted in the Persisted event > method of the new child node during its persist operation. > > The issue arising in the Json Viewer is that the transient link object > disappears from the adapterMaps between the initial method invoke and the > persist invoke resulting in a 500 Internal Server error with the message > "TOID : <hex value> and stack trace "causedBy:" value of null. > > > > Is the strategy as outlined in (3) appropriate for the Restful > implementation, and perhaps you could elaborate on the session management > for the Server deployment type. I have assumed that a session is created > upon authentication, and that server side session state including > adapterMaps would remain valid across multiple Http requests until a user > logs out, or the session expires after some preconfigured duration of > inactivity. > > > No, adapter maps will NOT remain valid across multiple Http requests, introducing server-side state in this way would be distinctly unrestful. Right now your only option is to convert the transient object into a persistent one, perhaps keyed by GUID and (conceptually) owned by a particular user. Analogous to a shopping cart. In the future, Isis might implement something like the sketch for AddressableViewModels, see section 32 of the spec. This won't require a change to the RO spec itself, but would be an Isis programming model convention to allow transient objects to be simulated. HTH Dan [1] http://danhaywood.com/github/apache-isis. > Regards, > > > > Barry Woods > > > >
