I included currency in the framework because i18n libraries the
framework is based on will include it.
A "framework for ERP applications" would be built on the framework I
proposed - I mentioned that in the document. In my mind, things should
be modular, instead of the monolithic design we have now. So, geos would
be a separate component that uses the framework - just like scripting is
a separate component. The framework plus a selection of additional
components could comprise a "framework for ERP applications." I believe
this approach will broaden the user base because we will eliminate the
"all or nothing" approach used now.
I understand the workflow you are suggesting - cut down the size of the
existing framework and then switch to something else. In an ideal world
we could do that. Unfortunately, we have a lot of committers who believe
more is better, so while we're cutting down in one area, someone else
will be adding code in another area.
The workflow I pictured was to introduce a new component and build from
the ground up. Initially there will be some code duplication due to
parallel development paths, but once the new component is finished,
other OFBiz artifacts can be updated to use it and any excess can be
removed. In other words, the code removal is motivated by the fact that
it is no longer needed.
-Adrian
On 3/1/2012 10:15 AM, Jacopo Cappellato wrote:
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
