On 2010-02-17 14.07, Niclas Hedhman wrote:
Ok, that is a lot of details to consume. But in general, I think I understand the overall approach, its benefits and agree that it looks "kickass". The problems I see is "learning curve", which ties into the ability to decompose a problem into different "concern scopes". When the solution is provided like this, it may look simple, but when the domain is more muddy (normally the case) this can quickly become a huge obstacle in new projects (perhaps an excellent consulting business in itself!).
I agree. It is easier to just have a "User" POJO and dump all your stuff related to "User"-ness in there, as opposed to having a UserEntity with UserAuthentication, UserProfile, GroupMemberships etc. to handle the various usecases. But one can always start with a "dumping ground" approach, and then refactor as you go along. The structure we have now, where each thing is in its place, took a long time to get to. Being able to refactor mercilessly without having to consider old database schemas is a very nice thing to have to accomplish that.
Having the Rest handler (seems almost enough reason to drop Restlet dependency) in a standard library with a full sample (let's say the User Profile case you talk about) in source code available is a good start, but we will need to write a lengthy piece on how this approach/pattern is done in a 'general' fashion, how to identify the contexts, how to separate the domain logic from other concerns, how to partition Rest URLs and many other details that quickly swamp someone how tries this on his/her own.
Very true. Like I said, you can start with a basic approach where the domain model has simplistic "all-in-one" interfaces, and then let the contexts for Rest purposes map to that directly. And then refactor as you explore the domain. Since there is almost no overhead in doing the refactoring (change the context=change the REST API, and it's self-described anyway), evolving your application becomes so much easier.
And to me, of course, being able to evolve the application easily is MUCH more important than saving a keystroke here and there as so many other frameworks focus on.
It is also an interesting insight about the "can this method be called", and it would be really cool if Java allowed one to reference a method directly and statically, so a more direct approach could be taken. Guess we need to save that for "Qi, the language".
For the REST handler it's ok to do it using reflection, since it is write-once code. For a more general approach it would have to be in the language. There has been talk about introducing methods as first-class citizens in Java, but no result so far.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
