The document is interesting and I agree with the approach in general. I don't agree, but this is a small detail, with the assertion that "currency" should be part of a framework: I can think of several applications not dealing with money :-) And if we want to design a "framework for ERP applications" then we could have some additional pieces (like Geos, Uoms, Currencies)... but this would be more a "common" base to ERP applications. I like the idea of "one component" framework: at that point it would be easier to deploy and we could use an external tomcat as the default setup (no more embedded catalina). I also think that the "official OFBiz ERP" (i.e. the features currently in the "applications" folder) should also be implemented by *one* application/component: based on naming conventions and patterns to simplify customizations and reuse but still one application where features are hidden thru permissions.
But this is for OFBiz 2.0, nice to discuss, but my idea for a lightweight framework was less revolutionary and could be considered as a preparation step in the direction of the new OFBiz: cutting down old branches and unused code in order to have a smaller system to refactor according to the new vision. At that point, with a cleaner ground, we could better plan the next step: implementing a new framework or considering other options (e.g. Moqui) or even keeping what we have Jacopo On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote: > As far as I know, most scripting engines have some sort of embedded cache. > The problem will be that we can't clear the embedded cache like we can with > our own cache implementation. I don't see that as a show stopper - it's > mostly inconvenient. > > I can help out with the conversion. I don't think the task will be that hard. > > Regarding a slimmed down framework, I proposed one some time ago: > > https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision > > and that document was in response to David's proposal to base OFBiz on Moqui > (another option). > > -Adrian > > > On 3/1/2012 8:53 AM, Jacopo Cappellato wrote: >> Implementing JSR-223 should be rather easy but if I am not wrong it would >> prevent the ability to cache the scripts (task that is currently done in >> org.ofbiz.base.util.GroovyUtil, that is using the the more flexible >> GroovyClassLoader mechanism); we could probably use the >> javax.script.Compilable interface but I am not sure... >> One advantage of JSR-223 would be that we could dynamically select the >> script engine based on the (for example) file extension without the need to >> maintain several classes like GroovyUtil, BsfUtil etc... >> The idea would be that, instead of having a GroovyUtil class we could have a >> generic ScriptUtil class with code like the following: >> >> ScriptEngineManager manager = new ScriptEngineManager(); >> ScriptEngine scriptEngine = >> manager.getEngineByExtension(fileExtension); >> Object result = scriptEngine.eval(scriptFileReader, scriptContext); >> >> and this code would be generic and could be used to plug in all the >> scripting engines that support JSR-223. >> >> However doing this in OFBiz would mean that we have to refactor all the code >> that is currently using the various<script>Util classes and in my opinion a >> simpler path (that is inline with Erwan's proposal to convert all remaining >> beanshell snippets to Groovy and then deprecate or remove BshUtil) would be: >> >> 1) migrate the remaining Beanshell snippets to Groovy >> 2) deprecate or remove (I see a lot of value in having lighter framework >> [*]) Beashell support (and other artifacts related to old/unused script >> engines) >> 3) (optional, something for the future) refactor the GroovyUtil class (and >> code that is using it) to be generic (ScriptUtil) and convert all the >> calling code to use it in a Groovy unaware way; this will implement the >> JSR-223 >> >> In this way, when we will work on #3 we could concentrate only on migration >> of groovy classes rather than having to cope with several other technologies >> (removed at #2) >> >> Kind regards, >> >> Jacopo >> >> [*] In my opinion one of the main big steps that the OFBiz project should >> consider is to greatly slim down the framework and only support the >> technology we really need (picking the best for each task); then with a much >> smaller codebase, we will be able to quickly improve the framework (less >> code to maintain etc...) to be compliant with new standards etc.. (e.g. >> JSR-223). For example in this context: ideally the OFBiz project should have >> all the scripts implemented in Groovy (one technology) and a simple way to >> integrate other scripting languages; we could achieve this implementing >> JSR-223 so that even the OFBiz code would be using javax.script.* rather >> than groovy.* packages OR it would be also fine if we would still be using >> groovy.* packages but in a clean way (e.g. all calling code could use >> interfaces to hide Groovy specific code) so that adding a new script engine >> would be easy (but the support of the new script engine will not be included >> in the project to keep it light and focused) >> >> >> >> On Feb 27, 2012, at 3:53 PM, Erwan de FERRIERES wrote: >> >>> Le 12/02/2012 20:43, Adrian Crum a écrit : >>>> It would be nice if we could come up with a way to use JSR 223 in screen >>>> widgets and mini-language. >>> Adrian, >>> >>> would this mean that we'll be moving from >>> groovy.lang.Script >>> to >>> ScriptEngineManager and ScriptEngine ? >>> >>> Do you think this would be a big task to accomplish this migration ? >>> >>> Regards, >>> >>>> -Adrian >>>> >>>> On 2/9/2012 6:31 AM, Jacques Le Roux wrote: >>>>> After almost 4 years, I can see no problems with that >>>>> Jacques >>>>> >>>>> From: "Erwan de FERRIERES"<erwan.deferrie...@gmail.com> >>>>>> Hi all, >>>>>> >>>>>> in may 2008, we decided to move from beanshell to groovy >>>>>> (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell). >>>>>> >>>>>> >>>>>> Since this time a lot of migration has been done, but still some >>>>>> snippets are remaining in the code (mostly in screens). >>>>>> >>>>>> What do you think of removing all the remaining bsh code, as well as >>>>>> its support in OFBiz ? >>>>>> >>>>>> Regards, >>>>>> >>>>>> -- >>>>>> Erwan de FERRIERES >>> >>> -- >>> Erwan de FERRIERES >>> www.nereide.biz >
