Chiming in;
As it happens I'm currently working on a NoSQL (Cassandra) project and found a JPA implementation for Cassandra (http://code.google.com/p/kundera/). Currently JPA is the most used persistency API in Java, allowing for binding with RDBMS, XML, NoSQL. I decided not to use it, BTW, but that is because of other considerations. To also have an quick opinion on the rest of the thread (as I understand it). Java projects have a tendency to over complicate and bloat. For example, wicket convention dictates that all labels should be put in property files. I decided not to do that. I fully understand the advantages, but for this project I'm simply not going to add an additional label component and a property file just to get "Name" on the screen. Yes, if it must be internationalized I have to rework my code, but as it stands the application probably won't have to be, and I would have added the abstraction for nothing. Same goes for the 6 line JPA example a few posts back. If it works, great, just use it as is. Why make it more complex from the start? Refactor if you need to, not overarchitecture in advance. I found that this pragmatic style (mind you; it's all a balance, you can't skip every corner), usually delivers results "PHP style" fast, but still has "Java quality" architecture in the overall setup. And even with all refactoring counted in, it stays well within budget; I'm currently aiming to complete my project in 75% of the "Java architecture" estimate. ;-) Coming full circle; one of the corners you can't cut is clear separation of concern. So extracting the model (JPA) from the presentation (wicket) is very important. My 2 euro cents. And thanks for a well though through framework, I'm warming up to it. Tom On 2012-05-13 09:51, dhar...@yahoo.com wrote:
Has your company heard of NOSQL?
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
