Hey, Now that Qi4j is sort of usable I wanted to try and fix up PetStore as an example of how to work with it, and also as a showcase of what happens when you work with mixins and concerns.
The JavaEE BluePrint PetStore works a lot with AJAX 2.0 these days so it's non-trivial to get into the code and see how it works. Another problem is that preferably I would have wanted to just take the web-part and use that as-is, since Qi4j is not about doing a new kind of web-framework, but the license for PetStore does not allow that. So the question is what to do with it. One way is to scrap the web front-end entirely and instead create a Swing-frontend, which is muuuch easier, and also shows off one of the main features of Qi4j: there's no need for value objects to work with entities on the client! I have no problem with this, but then again another thing to show off which would differentiate between this and other approaches is the DDD-aspect, which would be more clear if there were TWO frontends (Swing+web), or even THREE (Swing+web+REST). That would show how to partition your code so that application logic can be shared between many application front-ends. Not sure how far to take this though. Any ideas? Where to start? Is this the right direction? In your mind, what do we need to show for people to understand the power and simplicity of Qi4j? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
