commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [Jelly] BCEL Taglibrary Beginnings
Date Mon, 20 Jan 2003 20:23:20 GMT
I'm interested in the possibility that the BSF Taglibrary code could be 
reused to do this. Possibly through use of  the ExpressionFactory and 
manipulation of the ObjectRegistry used. Maybe by providing a means of 
switching form the JellyContextRegistry to a ObjectRegistry native to 
BSF. The BSF taglibrary code could be reused in the <body> tag to attain 
use of BSF scripting in the generated class that is "context 
independent" of Jelly while reusing the Expression/ExpressionFactory 
code already implemented to easily provide the scripting support. It 
might be even possible to provide the ability to reuse BeanShell as 
scripting environment via this methodology as well.

Properly implemented it may be possible to "toggle" the registery used 
as to provide access to the JellyContext for classes that will only be 
used inside of the current Jelly instance, as opposed to classes that 
may be generated, saved and used later on in some other JVM 
instance/Thread...

-Mark

Juozas Baliuka wrote:

>I have read jython documentation and seems this tool can not help, it
>generates JAVA source code and uses javac to
>compile stuff, classes returned from evaluate are internal data structures.
>But it is possible to implement with most of scripting languages, generate
>byte code for somethng like this:
>
>
>class MyClass extends SomeClass implements Interface1, ... {
>
>//evalutes script
> int myMethod1(int arg ){
>
> return  ( (Number)BSFUtils.evalute(
>        this,
>        new Class[]{ int.class, SomeClass.class } ,
>        new String[]{"arg","super"},
>        new Object[]{ arg , new $MyMethodToSuperDelegate$(this) },
>       "javascript",
>       "super.myMethod1(arg1) + arg1*arg1"
> ).intValue();
>
>}
>
>//used to implement "super.myMethod(arg)"
>int $myMethod1$(int arg ){
>   return super.myMethod(arg);
> }
>}
>
>//used to implement "super.myMethod(arg)"
>
>class $MyMethodToSuperDelegate$ extends SomeClass implements Interface1,
>...{
>  MyClass obj;
>   $MyMethodToSuperDelegate$( MyClass obj ){
>    this.obj = obj;
>  }
> int myMethod1(int arg ){
>        return  obj.$myMethod$(  arg   );
>  }
> }
>
>}
>
>BSFUtils puts suff to BSF Context and evalutes script, generated class will
>be visible as "normal" JAVA class.
>
>
>  
>
>>Juozas Baliuka wrote:
>>    
>>
>>>Methods can be generated too:
>>>
>>>    <bcel:method name="methodName" returns="int"   >
>>>      <bcel:arg type="int" name="arg1"/>
>>>      <bcel:body language="javascript">
>>>          <!-- Script to evaluate  --->
>>>             super.methodName(arg1) + arg1*arg1
>>>      </bcel:body>
>>>    </bcel:method>
>>>
>>>It can implement or override methods this way, but  It can be possible
>>>      
>>>
>to
>  
>
>>>implement without BCEL,
>>>I am not sure, but it seems jython can extend/implement JAVA
>>>classes/interfaces and return
>>> jython classes as JAVA types.
>>>      
>>>
>>Hmm,
>>
>>I actually have played around a bit with some custom tags, what they do
>>is pickup the "Script" body out of a JellyTag and execute it when a
>>specific method is called.
>>
>>ie.
>>
>><setup>
>>....
>></setup>
>>
>>
>>gets called by my class:
>>
>>     private Script setup;
>>
>>     public void setup() throws Exception{
>>         if(setup != null && context != null && output != null){
>>             setup.run(context, output);
>>         }
>>
>>     }
>>
>>I suspect this wouldn't work if the class were created in Jelly then
>>used later  on elsewhere outside of Jelly because the instance of the
>>Script would be gone. However, it works rather well as long as an object
>>instance on of the class is created and used within the "scope" of the
>>Jelly Interpreter.
>>
>>SideNote: I'm not sure how kosher it is to use "parts"/"instances" of a
>>tag outside of the scope of the tag, I know this isn't recommended for
>>JSP Taglibraries by the Jakarta Taglibraries crew. Primarily because
>>they don't promise that the instance of the tag will be there (or that
>>it may have be reused when the tag is encountered again in the JSP). I
>>think they recommend using a "Data Model" or "Bean" behind the tag to
>>support the functionality that my be required outside the scope of the
>>    
>>
>tag.
>  
>
>>As Tomcat now supports Tag Caching and reuse for JSP's is there any
>>thought how this would effect issues as well in Jelly?
>>
>>-Mark
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>>    
>>
><mailto:commons-dev-unsubscribe@jakarta.apache.org>
>  
>
>>For additional commands, e-mail:
>>    
>>
><mailto:commons-dev-help@jakarta.apache.org>
>  
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>  
>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message