cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon 2.0: proposed battleplan
Date Mon, 10 Apr 2000 18:42:11 GMT
rubys@us.ibm.com wrote:

> >Sam, do you have any ideas on how this can be implemented?
> 
> Quite frankly, that's what you need something like BSF for.

Yeah, I figured that out. :)
 
> The way you approach a problem like this is you canonicalize it.  You pick
> a single internal implementation language and get it work well - nobody
> would be interested in testing for the wild number of possible permutations
> involved.
> 
> >From what I've seen, I would suggest that the right default language for
> Cocoon is Java.

+1
 
> Now you need something that will "compile" code in the user's choice of
> language into Java.  Three interesting cases:
> 
> 1) The language that the user chooses is, in fact, Java.  In that case,
> BSF's job is real easy...it simply hands you back the string.

ok
 
> 2) The language you pick can be transliterated into Java.  NetRexx can be
> done this way.  In which case, there is a translation done and you are
> handed back Java to process.  This is actually only a small number of cases
> however.

makes sense
 
> 3) The language is a pure interpreter.  Two interesting subcases of this
> are JVM based languages and non-JVM based, but for purposes of this part of
> the discussion there is no difference - what is done is that the code is
> suitably quoted and inserted into a "bsf.eval" call - and executed at
> runtime.

makes perfect sense (but don't tell me to write it!)
 
> The beauty of such an approach is that if something doesn't work right with
> a particular language, and does work with Java, then you have pretty much
> isolated the problem down to the component that is causing the problem
> (BSF).  

Ok.

> Furthermore, if the language you are interested in is Java, the
> support for other languages incurs exactly zero overhead at runtime and an
> almost undetectable (string compare and method call) overhead at compile
> time.

Cool.
 
> There are some messy details that I'm glossing over (parameter passing, for
> example), but essentially that's the picture.
> 
> Getting back to the original point, on a page such as:
> 
>    <xsp:page language="jpython">
>        <xsp:expr>Date()</xsp:expr>
>        <util:date/>
>    </xsp:page>
> 
> The author of the util tag either needs to know and support all possible
> page languages (yuck!), or explicitly specify a language of java on all
> <xsp:expr> or <xsp:logic> tags (grumble!) or be able to specify a default
> language for the taglib (with the default for the default being Java).
> 
> I prefer the third option.

me too.

So, for what I can understand from your picture, the impact of
multilanguage support is both on the taglib filter (responsible of
generating the pure XSP code) and on the page-compiler/serializer (which
should perform this BSF wrapping when compiling the page).

Is this right?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message