#527 Turning users to programmers: Jython scripting in Compiere

closed-postponed
nobody
5
2005-09-26
2005-09-25
No

Python is a very elegant and powerful scripting
language, it's main benefit is that it is so damn easy
to learn that it turns users easily into programmers.

Jython is Python implemented in Java. It can both use
Java classes and compile to Java bytecode and then
Jython classes are usable from Java, and usable as an
integrated scripting environment, with interpreted
code. It is easy to integrate the interpreter to any
Java app.

I tried to rewrite a callout to Jython, although I
could not test it (don't know how to recompile the
client), the experience was that

A) There is no radical difference, no big things to
learn as it is nothing else but calling the same
classes in a similar OO way, with a little of syntax,

B) Dynamic typing and the lack of brackets (Jython uses
indentation to mark blocks) make the code about 50% as
much lines long - thus easier to read - and maybe 80%
as much characters long (so the main screen lines save
is the empty lines that contain nothing but brackets).

My suggestion would be

1) Integrate Jython as an interpreted callout scripting
environment - I think it must be easy, just a new field
in AD_Field that stores the Jython code and integrating
the interpreter to the client. (Of course the
integration of some Scintilla-like editor control stuff
is also necessary, I think we can find many free, open
source solutions to this.)

2) It is easy to write scripts that read the Java code,
and generate the code of the current callouts in Jython
- the difference between these languages is easy to
define programatically.

Discussion

  • Miklos Hollender

    • summary: Turning users to programmer: Jython scripting in Compiere --> Turning users to programmers: Jython scripting in Compiere
     
  • Miklos Hollender

    Logged In: YES
    user_id=1317526

    Info: on embedding a Jython interpreter:

    http://www.jython.org/docs/embedding.html

    import org.python.util.PythonInterpreter;
    import org.python.core.*;

    public class SimpleEmbedded {
    public static void main(String []args)
    throws PyException
    {
    PythonInterpreter interp =
    new PythonInterpreter();

    System.out.println("Hello, brave new world");
    interp.exec("import sys");
    interp.exec("print sys");

    interp.set("a", new PyInteger(42));
    interp.exec("print a");
    interp.exec("x = 2+2");
    PyObject x = interp.get("x");

    System.out.println("x: "+x);
    System.out.println("Goodbye, cruel world");
    }
    }

     
  • Jorg Janke

    Jorg Janke - 2005-09-26
    • milestone: --> Target Future Release
    • status: open --> closed-postponed
     
  • Jorg Janke

    Jorg Janke - 2005-09-26

    Logged In: YES
    user_id=87038

    Implemented BeanShell as it is also the Java standard of the
    future. The main issue is that users can circumvent any
    secuity.

     
  • Eldir Tomassen [ActFact B.V.]

    Logged In: YES
    user_id=590380

    Yes, causing all kinds of havoc is a nice demonstrational
    purpose of the current scripting functionality.

    on topic:
    I agree that BeanShell is the way to go, it is a very
    capable environment, with recent versions you can even use
    BeanShell defined classes from Java. (implemented with
    reflection & proxy)

    It would be most valuable to be able to use BSH for
    Callouts, before/after safe triggers, procedures etc.

    User level scripting is nice to have (should be restricted
    on role basis)
    but less important.

     
  • Miklos Hollender

    Logged In: YES
    user_id=1317526

    Dear Eldir,

    does BSH provide the same short, concise way of programming
    than Jython? You know, my greatest problem with the whole
    Java culture is that they think typing much is not a
    problem. Which means they think that it is possible to
    design software on paper, which is actually impossible
    (extreme programming is the only thing that works). And even
    more a big problem is reading Java code, as important things
    are being concealed in the huge quanttity of meaningless
    detail, such as the static type definiton of variables and
    such stuff. This is why I am suggesting a more concise tool
    for this great project.

    Remember, it is always totally unimportant, what an ERP
    software can or cannot do, because you always have to
    totally reprogram it to suit the taste or culture of the
    client if you want to make them really content - the only
    important thing is the easiness of reprogramming.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks