a) ad "usage of scripting languages in the context of JSP is rather unnatural": why *unnatural*, for God's sake? I see the contrary to be true, opening up JSPs to solving problems in non-Java languages as well, *if* fitting. As important as Java is, there are applications/problems where non-Java-languages may be preferable, e.g. from scripting to interpreting dynamically created statements.
[BTW, Microsoft allows to use *any* scripting language for their ASP, ie. the JSP counterpart on Windows: they support any WSH-scripting language out of the box.]
Could not resist to put few words. I think it is better to let each scripting language to connect to JSP directly without intermediate layer of BSF. The issue here is not a performance (I doubt that BSF layer has
Well, the "intermediate layer BSF" is exactly the plumming one needs to have available to *easily* allow Java programs to invoke non-Java languages and allow those to "call back" into Java.
Or with other words: if there was no BSF available one would have to re-invent and re-implement most of the functionality which BSF offers for "free". So your suggestions would impose more workload on the shoulders of people trying to bridge Java with other programming languages, resulting in numerous different implementations of that particular bridging (and in addition each individually created plumming infrastructure would have to be tested individually).
OO-programming is about re-using, frameworks the same. Having BSF in place already allows one to re-use a tested framework and thereby cutting development costs and debugging time (w.r.t. the BSF infrastructure).
any significant impact here) but simplicity and convenience of direct plugin implementation over using BSF as super-plugin that comes with own plugin children.
Oh, BSF is about elegant simplicity, there is no overhead imposed by BSF which you wouldn't have to create yourself (just think about the issue of creating event adapters yourself, not speaking of the need of reflection, just look into the BSF source code to see what those people have nicely achieved!).
Or putting it into even other words: if someone sees the need to bridge Java with another programming language (which should also be able to "call back"), I would regard it to be a stupid decision, not to take advantage of BSF, which solves the principal briding problems.
After spending few years to implement all MSIE quirks and extensions for JavaScript and DOM in a pure Java browser while keeping an option to use
Jython on web pages I think any intermediate library will either harm a particular language power or lead to extremely complex and unmaintainable library.
That depends on the chosen implementation.
Microsoft tried to allow to use VBScript in HTML and keep things compatible with Netscape DOM bindings for JavaScript and the end result is the complete and final mess in DOM scripting in MSIE that I suspect nobody understand.
I do not concur with this view, DOM in the context of a WWW-browser by itself is a rather complex biest and there are too many people not even knowing about DOM but using DHTML by extending existing examples.
Also, the WWW-browser area is one area which upsets me if you witness the phenomenon, that for all practical purposes JavaScript only is supported out of the box for scripting HTML pages. MS Internet Explorer being the *only* browser which supplies an "open" (it is *not* that open at all) interface for people to allow other scripting languages to be used for that purpose, out of the box: JScript and VBScript (it may have been for the VisualBasic language that MS opened its browser for more than JavaScript to be used for scripting HTML pages).
Server side ASP is not better. Yes, you can write ASP in JavaScript or Perl, but often you end up with terrible hacks just to subvert ASP VBScript-based conventions into a particular language.
No! I know, I have been doing that exact thing for quite some years as well. No need to use VBScript semantics at all (but one could use the VBScript sample programs as well as the JScript sample programs to learn what can be done with WSH).
Similarly Python and JavaScript are just too different to have a simple library that covers everything.
Well, you need to implement the ActiveX interfaces for the Windows Script Host (WSH) engines (WSE), which is not an easy task, because AFAIK not all vital information is documented (I remember at one time that ASP was not possible with a particular programming language due to a necessary registry entry one had to supply; if you didn't supply that by default a VBScript prolog and epilog was "injected"). [Any WSE-compliant programming language can be applied for MSIE, ASP and {c|w}script applications and any other scriptable WSH application. It is even possible to define COM classes, implemented in such scripting languages.]
An brief overview about scripting/automation under Windows (starting out with COM, ending with .NET) with a programming language with a syntax like pseude-code (so the code should be ledgible/understandable by non-proficient persons as well) can be found at:
<http://wi.wu-wien.ac.at/rgf/diplomarbeiten/2003_Helmecke_A/MasterThesis_AutomationOfWindowsApplicationsWithObjectRexx.pdf>
It uses Object Rexx, a commercial product by IBM (I am not affiliated with IBM at all, sometimes just a happy customer) freely available for Linux and OS/2, costs a little fee for AIX and Windows (but freely available for educational institutions for the purpose of teaching and researching via IBM's "Scholar" program).
Regards,
---rony
P.S.: There is a JCP initiative at Sun to explicitly allow Java to invoke scripting languages, cf. <http://www.jcp.org/en/jsr/detail?id=223>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
