Heh - I just got called on my remarks below via twitter. Characterizing Isis as a "UI-focused metamodel" was wrong of me; it is ultimately all about the domain model. But I guess when I wrote that I was just thinking about how Isis might come over to someone who's encountering the idea for the first time. A pure domain model is all very well, but it's somewhat theoretical - people like to see things, after all. (And those things they see had better be pretty... which is a whole other conversation....)
Dan On 15 March 2012 10:22, Dan Haywood <[email protected]> wrote: > 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 >> > >> > >
