2009/11/14 Rickard Öberg <[email protected]> > On 2009-11-12 16.42, Jacek Sokulski wrote: > >> I would even say strongly interlinked. It looks like doing OO in C, it >> is possible but one needs to stretch the language a lot and sometimes do >> magic tricks. >> > > True. One reason I wanted to stick with Java was because I looked at > AspectJ, which introduced a new language, and don't think that it really > worked out all that well. So we stuck with "Java++", in the sense that we're > using the Java language with the extensions made possible by using > annotations. I still believe that was a correct decision. > > > I would see step by step way to Qi4j something like that: >> >> 1. More theory - what is it all about. One can find some pieces here and >> there but it is time consuming and it is not clear what is still >> current. At least you could put in one place links to some threads from >> the list (like one on what is object - explain a lot, or one on entity >> patterns) and other useful staff in the net (posts from Rickards' blog). >> > > Agree, the docs needs to be better structured. > > > 2. Look, you can do some valuable staff without the whole Qi4j >> infrastructure (or some minimal subset of it), like traits. >> > > Yes, you can start with just some basics. I would suggest that Constraints > is a good minimum to start with, since many people are wasting time writing > "if (foo == null) throw new NPE" code, which should be unnecessary. > > > 3. Now you can model one domain with Qi4j and integrate is with the rest >> of the application, so an examples/tools/extensions how to integrate >> with Qi4j app as library, services or anything else would be helpful. >> > > AFAIK Qi4j has two-way Spring integration, which might be a start.
I think it is quite important. Two points that raised most discussions in our team was integration and lack of RDBMS persistency. It is not the point if Spring or the RDBMS persistency is good or bad (anyway I think with Qi4j RDBMS persistency many developers would not found in DB what they had expected), but of human habits (and sometimes corporate policy) - it is easier to give up one habit at a time than five. It would be goo to have Spring integration HowTo, I'll try to play with it and write some points. > > > 4. You are ready to take fully advantage of Qi4j >> >> Maybe it would be good to separate COP and DDD concepts/infrastructure >> they are two separate concerns that interfere a lot in studying Qi4j. I >> think it would be easier to get first COP only, especially for people >> who do not know DDD. >> > > I think that the recent DCI track we had at Oredev will be helpful. Once > the videos are up, in which Trygve Reenskaug, Jim Complien and me explain > why OOP in its current incarnation doesn't work, that will be most helpful > to stop thinking of COP as an alternative to OOP, and instead think of it as > a necessary evolution from OOP. It really does make things much easier and > allows us to get out of the complexity nightmare that todays tools bring > with them. I am following DCI from some time, it is where from I have found Qi4j, I think both ideas support each other very well. > > > Right, If you use any technology a lot, backing out is usually a >> problem. Even migrating between to versions of the same >> all-standard-based-J2EE-server like JBoss is a big headache. But they >> give you at least a mirage of not lock-in, so one can sleep well, until... >> > > Yes, we are not going to suggest that there is a way to "back out". But > once you're used to the Qi4j model, you wouldn't want to anyway. All > developers that try it have a period of confusion initially, but eventually > it dawns on them, and then you'd be terribly frustrated to do it any other > way. We just have to work on minimizing the confusion period :-) > > /Rickard > > Jacek
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
