jakarta-bsf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rony G. Flatscher" <Rony.Flatsc...@wu-wien.ac.at>
Subject BSF, DHTML ,... (Re: re-organizing the BSF source tree
Date Wed, 18 Jun 2003 09:12:09 GMT
>
>
>> 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>.





Mime
View raw message