>
>
>> 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>.
|