On Apr 6, 2011, at 12:32 AM, alexander.reel...@lusini.com wrote: > Hi > > On Apr 5, 2011, at 9:08 PM, David E Jones wrote: > >> >> On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote: >> >>> Hi David, >>> >>> Congats on the beta release! >>> >>> You were asking for feature requests and today I ran across a java >>> framework called Play they have a few of things that might be interesting: >>> - they get their framework to compile java sources directly and then >>> hot-reloads the JVM [1] >> Taking a quick look at things I wonder if they are using Groovy to treat >> ".java" files as ".groovy" files. In Moqui the recommendation is to just use >> Groovy anytime you need a script for a service or other things. Of course, >> Moqui isn't so Java-centric as it seems like Play is, so runtime reloading >> during development is more of an inherent part of the framework and >> recommended tools as opposed to something that has to be added. > No. Play uses standard bytecode enhancement to shorten many things up (i.e. > autogenerating getters and setters if they are not set), which are bloated in > java. Groovy is used as part of the templating language only. The eclipse > compiler is used for live compilation on changes in development mode, if the > .java file is newer than the .class file.
Interesting. I've never felt the desire to get into direct bytecode morphing, but I suppose there is a lot of fun to be had there. This sounds like a lot of stuff Groovy does (auto getters/setters, etc), but I bet it's a lot faster if it doesn't do the runtime type checking/converting and other Groovy sugar. >>> - their logging seems to be very clear and would speed up bug finding [1] >>> [2] >> Yes, that is interesting. In OFBiz this is a HUGE problem because there is >> so much use of the hideous log & rethrow pattern which results in the same, >> or very similar, stack trace being logged half a dozen times. > Well, this is "simply" an implementation issue, you could also screw up any > play application that way... Yes, that is true, and it could certainly be cleaned up in the OFBiz applications and framework. >>> - they have a module repo to specify third party hosted module repos [3] >> I'd like to do this sooner or later with Moqui and list addons or plugins, >> plus a document about how to create them (I couldn't find a doc like that >> for Play, maybe I didn't look hard enough). That framework has various means >> of supporting this right now, but I like the idea of creating a page to list >> addons/plugins, even if it starts out empty... ;) > This is because modules are actually applications themselves (with minor > tweaks of course), but if you know how to write a play application, you have > all the basics needed for module writing. > > More generally talking about play: Concepts differ greatly between play and > frameworks similar to ofbiz - no xml hell, real objects instead of > map-defined entities (also making validation really simple), actually using > and understanding HTTP instead of interpreting it as a stupid transport layer > (this weakness exists in java since the definition of the servlet spec), > completely configurable URLs as entry point to your application, multi node > scalability due to true shared nothing architecture. Running tests in your > IDE or without restarting your whole system is also pretty nice, when you > want to call yourself test driven - any many things more. > > This should be enough marketing for today... :-) > > If you have time, you should take a closer look at play. It has pretty clear > concepts, some of them being quite radical and thus complex to port into > existing frameworks. > > > --Alexander (frustrated ofbiz dev on day, happy play hacker at night, > possibly somewhat biased ;-)) Aside from "xml hell" and map-ish entities instead of objects, and the occasional use of the servlet session instead of shared nothing, what is it that frustrates you about the OFBiz framework? In other words, what bothers you on a regular basic or makes things slower for you than you'd like, or than you'd anticipated? -David
