Ok you convinced me, I give up. At least I see somebody tested what I was going to do. As I see, it looks like velocity id perfect peace of software (performance I mean).
Before I thought I was 100% sure, compiled code has to be much faster than interpreted. Now I thing that guys at groovy did somthing not in the best way. So will see what will come in the future out of groovy. BTW what is better solution: BeanShell, Rhino, JPython, Jelly or ...? Remis ----- Original Message ----- From: "Dag Liodden" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 04, 2004 12:12 AM Subject: Re: [OS-webwork] Groovy and WebWork > remigijus wrote: > > >Just note > > > >In your's blog you haven't mentioned anything about groovlets (aka groovy + > >servlet). They are somthing like servlets but much easier to use and is very > >like php. It needs only to add a groovy servlet and map all request with > >*.groovy. Evrything else will be handled automatically. > > > > > The base of the code is from the Groovy Servlet implementation and I've > kept the good parts (compilation of all scripts and dependencies is done > automagically). If you just want to do servlets php-style but keep the > xwork interceptor mechanisms, just put all code in the view, but that > breaks the design patterns. :) > > >Now webwork2 for UI tags is using velocity. It means that for every ww:ui > >tag there is velocity involved. With groovlet it is possible to easily > >replace all velocity templates in just one day or two the most (at least I > >hope :) ). And because grooblets are bytecode and they are cached by groovy > >servlet there I expect some performance imrovment. And it is still possible > >to use full pover of java language. > > > > > Initial benchmarks show that the Groovy script implementation is about > 50% slower than the Velocity equivalent. It seems to be that the > on-the-fly generated classes are slow. I see a lot of reflection going > on in groovy.land.MetaClass. I'll ask the Groovy guys about it and it > will probably be sorted out. If there's a difference between these > classes and the pre-compiled ones, we should at least be able to switch > to precompiled on deploy time. :) > > Dag > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
