Hi Mark, You're right is quite a lot of work, but it's something I've been thinking about for a very long while now. Right now Isis is too complex and reinvents too many wheels. That's not a criticism - some of that code was written before ORMs etc were mainstream. And quite a lot of that complexity was to support requirements - specifically, client/server - that just aren't mainstream anymore.
Does any of this matter? Well, yes - I think that the complexity is putting off would-be users of the framework, so it's something we need to tackle. Ultimately I want to pare Isis down to its central "value add"; which is basically a UI-focused metamodel with some viewers and a REST API that expose it. And ultimately, I hope all this will be CDI beans to fit in with JEE6/7, so it can be used in different contexts. This thread though, is the opportunity for anyone who wants to refine/challenge that view. ~~~ In terms of an ordering of the steps that I outlined, it's actually as follows: 2a. bring in the JPA objectstore's metadata - notably take creation of a facet for @DiscriminatorValue and generalize this into an ObjectTypeFacet. eg "CUS" is an abbreviation for com.mycompany.Customer. [I've started on this already] write a default fallback impl of ObjectTypeFacet that would just use the fully qualified class name as the "abbreviation". at same time, enhance the reflector to hold a cache of ObjectType 5a. Introduce a new Oid impl that has a serialized string format of "ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456". 3. delete the remoting 4 & 6. look to see what's left in terms of OIDs being immutable and transient, and move responsibilities. 5b. Rework existing objectstores to use this new Oid impl (and make final, why not?) 7. make HTML viewer stateless 2b. Complete port of JPA object store to use the new Oid infra 1. Complete working on JSON viewer. Perhaps not all of that will make it into 0.3.0-incubating, but that's the plan I intend to work to. ~~~ Please, all, let me know your thoughts; otherwise I'm assuming lazy consensus. Dan ~~~~~~~~~~~~~ On 15 March 2012 07:20, Mark Struberg <[email protected]> wrote: > Sounds good! > > +1 > > I'd do 6 and 7 only if there is time left. This is quite a radical change, > isn't? > > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Dan Haywood <[email protected]> > > To: [email protected] > > Cc: [email protected] > > Sent: Wednesday, March 14, 2012 12:20 AM > > Subject: plans for 0.3.0-incubating... > > > > All, > > Just wanted to outline some of what I intend to work on for the next > > release. Since some of this involves deleting (archiving off) code, this > > is an opportunity to put forward an alternative view. > > > > 1. json viewer, implementing the Restful Objects spec. Nothing too > > controversial here. I might rename it back to the "restful viewer", > > though > > (now that the xhtml-viewer is history). > > > > 2. bring in the JPA object store, ditching its reliance on Hibernate (not > > compatible with ASF license policy) and replace with Apache's OpenJPA. > > > > 3. DELETE the dflt runtime's client/server remoting support. This has > > never been used in anger in Isis (it was used on the original Naked > Objects > > framework, but only when running as a .NET app). If there ever were a > > desire to reintroduce a client/server viewer, then the json/Restful API > > will make a more than adequate replacement. > > > > 4. with remoting gone, simplify the dflt runtime's codebase. In > > particular, the Persistor vs ObjectStore APIs can probably be simplified. > > > > 5. make OIDs fully self-describing, so that they identify the class as > well > > as the identity. When I look at the "real" objectstores (XML, SQL, > > NoSQL, > > JPA), they all do this anyway; the only one that doesn't is the in-memory > > object store. Ideally we should be able to have a single Oid class > (rather > > than have every objectstore implementation define their own variant). > > > > 6. [A BIT MORE CONTROVERSIAL]: make OIDs immutable, and get rid of the > idea > > of OIDs knowing the state (persistent vs transient) of the object that > they > > identify. The main reason we have this is to support client/server > > remoting, whereby an object starts off as transient when it leaves the > > server, but when it comes back the OID needs to capture the fact that the > > client wants it to be persisted. I'm not exactly sure what the final > > design is here, but I'm pretty sure by moving some responsibilities about > > subtly we should be able to make OIDs truly immutable. > > > > 7. Make HTML viewer stateless, for persistent objects at least. This > > follows on from (6); it will also make it possible to develop on the HTML > > viewer without having to logout/login on every deploy cycle (as we > > currently have to do). > > > > ~~~ > > I'll be making a start in the next couple of days on some of the > > non-controversial stuff; shout out if any of the above concerns you. > > > > Dan > > >
