[
https://issues.apache.org/jira/browse/ISIS-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940260#comment-13940260
]
Dan Haywood commented on ISIS-743:
----------------------------------
I can tell you sound a bit disturbed about this idea... let me see if I can
allay that.
Start with... you ask about the link with transient objects.
Back in time, when Isis was still Naked Objects Framework, the main production
deployment was the drag-n-drop viewer with a client/server architecture. (This
is the architecture that still runs in the big government system in Ireland).
This architecture does/did fully support transient objects, in the sense that a
transient object is a domain object that might or might get persisted. Any
actions invoked on it are invoked client-side, within the DnD viewer. Its Oid
(object identifier) is basically a GUID. If the object does get persisted,
then it is sent to the server, and is returned with a n updated Oid, being the
one assigned by the server-side object store. There was lots of horrendous
code involved to do with syncing the identity maps that associate
Oids/pojos/ObjectAdapter wrappers when this happens... I was very happy to
remove this code when we dropped client/server support a few years back. The
Restful Objects spec refers to such transient objects as "proto-persistent".
In the Irish system we also have used (or perhaps mis-used) transient objects
to act as a view model, eg for bulk entry and like an extended action prompt.
Here the user enters data into the transient object (and perhaps child
transient objects). Invoking an action on the transient object then generally
goes off and updates/persists a bunch of other data. The @NotPersistable
annotation was a way to suppress the "save" button from being rendered in the
DnD viewer.
So, historically, transient objects have had these two roles... to act as
genuine proto-persistent objects, and to act as a view model of sorts.
In the Wicket viewer, things are necessarily different, because there is no
client to hold the state of the transient object. The same effect is
achievable though, because Wicket is stateful, and so each rendered page is
held in the user's HTTP session and so can encode the state of a transient
object. The Wicket viewer's ObjectAdapterMemento class basically does this...
if the object is persistent, we just serialize its Oid, but if the object is
transient, then we serialize the object's entire state.
That said, Estatio doesn't use this technique at all, so it could be buggy, and
- since I originally coded up that stuff - I've started to change my mind about
the desirability of transient object support in this way. The main reason I'm
changing my mind is because of the work I've been doing more recently on the
Restful Objects spec.
So, to talk about that for a moment... unlike the Wicket viewer, the RO viewer
is stateless; this absolutely must be the case. So the responsibility of
holding the state of transient objects moves to the restful client, ie outside
of scope of Isis. Now the Restful Objects spec does support transient objects
(calling them proto-persistent objects, as I mentioned). However, the
representation of a transient object has no Oid and no "self" link (ie URL)...
which makes sense because there is no resource on the server-side to address.
View models, however, are supported by the RO viewer. The Oid of a view model
is basically the encoded state of its values. This has the side-effect of
making it immutable, but that's not a bad thing; its actions can always return
a different view model.
Given that view models fulfill our historic requirements for what transient
objects have done, we're considering simplifying the RO spec in v2.0 and
dropping proto-persistents; they don't really fit in anyway. And so what this
ticket is about is the idea of removing the concept completely also from core
and from the Wicket viewer.
OK, that's the background to this. Let me talk about how I envisage you could
write apps in Isis where the persistence is managed by some external service.
A good example, actually, is context.io [2] that Dileepa on the dev list is
considering using for a Google Summer of Code project this year. Here
context.io provides a REST API to return information about email messages;
these are persisted elsewhere. How would write an Isis application that acts
as the front-end of sorts to these externally persisted emails? I see two
design alternatives.
The first is through a domain service, eg acting as a client to an external
service. If we wanted Isis to render a given email message, then we could
create a view model that acts as a wrapper around the JSON returned by that
domain service. The user could invoke actions on that Isis view model, which
would then interact through the domain service (eg to context.io) to interact
with the corresponding externally-managed object.
The second is to integrate a little deeper, by writing a custom Isis Object
Store. Here the object would appear to be a regular persistent entity as far
as the rest of Isis is considered, however its actual persistence would be
accomplished through calls to the domain service.
Writing an object store like this is a pretty serious undertaking, and so an
alternative is to configure to use the regular JDO/DN object store, but then
DataNucleus's own Store Manager API [2] to plug in some different persistence
mechanism. Given that DN has a whole bunch of Store Manager implementations
(including for example persisting to an Excel spreadsheet!), I'm expecting that
to be an easier thing to do than to write an Isis Object Store. (It's also why
I think we should ditch Isis ObjectStore API completely, but that's a different
ticket).
The attached diagrams show alternatives (1) and (2).
I don't know if the above missive helps dispel your fears or not. If not, I
guess the main question I have back is how would you tackle the addressability
issue that the stateless RO viewer introduces (if we just carried on supporting
transient objects as is).
[1] http://context.io/
[2] http://www.datanucleus.org/extensions/store_manager.html
> Remove the concept of transient objects and of @NotPersistable; instead we
> have view models.
> --------------------------------------------------------------------------------------------
>
> Key: ISIS-743
> URL: https://issues.apache.org/jira/browse/ISIS-743
> Project: Isis
> Issue Type: Wish
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Fix For: core-2.0.0
>
>
> For discussion; but think that view models supercede our earlier ideas of
> transient objects etc.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
