On Thu, Jul 8, 2010 at 10:52 AM, Rickard Öberg <[email protected]> wrote:
> I'm not sure. I have a hard time trying to imagine what it would look like, > without getting down and dirty myself with Wicket. And, from what I've seen, > Wicket is not a framework I would choose for doing webapps. So far, as I > said before, we are happy with the JS+CSS+HTML+REST approach, where the > serverside is strictly REST, and all the component handling is done in JS. > But we are early on, so might get bitten bigtime later on. Time will tell. Isn't a Wicket approach supposed to sit on top of the Rest API itself? You can then build whatever you want, without needing to figure out what part of Wicket app is in what DCI space... Now, whether you want to go through the network layer of Rest or want to short-ciruit that directly in code is then a tricky question. I would probably choose the network layer, since it gives more flexibility in deployment as well as easier integration testing for the DCI/Rest/Qi4j app. However, I think soon enough you will start thinking of "Why isn't Wicket made in Qi4j, so I can just stack my fragment for page assembly?"... That happened to me and I wanted to do Quikit/Qikit/Qicket, which would borrow a lot of Wicket concepts but fully leverage Qi4j and provide Qi4j with a RAD platform (all CRUD ops available from start)... Never got time to work on it though... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
