jstrachan 02/03/09 07:32:10 Modified: jelly OVERVIEW.html TODO.txt Log: Made a few changes to the overview document. Still needs a bit more work to explain what Jelly is Revision Changes Path 1.2 +33 -7 jakarta-commons-sandbox/jelly/OVERVIEW.html Index: OVERVIEW.html =================================================================== RCS file: /home/cvs/jakarta-commons-sandbox/jelly/OVERVIEW.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- OVERVIEW.html 4 Mar 2002 03:32:25 -0000 1.1 +++ OVERVIEW.html 9 Mar 2002 15:32:10 -0000 1.2 @@ -12,9 +12,35 @@ <h1>Jakarta Commons <i>Jelly</i> Overview</h1> -<p>Jelly is a simple yet powerful scripting engine. Jelly is totally extendable -via custom tags (like JSP) as well as cleanly integrating with other scripting -languages via BSF (Bean Scripting Framework).</p> +<p>Jelly is an XML based <i>processing engine</i>. The basic idea is that XML +elements can be bound to a Java <i>action</i> which is a Java bean that performs +some function. So Jelly is totally extendable +via custom actions (like JSP custom tags) as well as cleanly integrating with scripting +languages such as Velocity, pnuts, beanshell and via BSF (Bean Scripting Framework) +languages like JavaScript & JPython</p> + +<h2>Background</h2> + +<p>It seems quite common these days to define custom XML languages to perform +some kind of processing. Here are a few examples</p> + +<ul> + <li>Ant</li> + <li>XSLT</li> + <li>XML Pipeline language</li> + <li>JSTL and JSP custom tags</li> + <li>Latka, AntEater & other similar XML based unit testing frameworks</li> + <li>commons-workflow</li> +</ul> + +<p>So the motivation behind Jelly was to create a simple XML based processing +engine that could be extended to support various custom actions. A fully +qualified XML element name can be mapped to a Java Bean (or DynaBean), the +attributes map to bean properties, once the bean is constructed and the +properties set it is executed via the Tag interfaces run() method. So custom +actions can perform all kinds of processing from lower level looping, +conditional logic and expression evaluations to higher level actions like making +a HTTP, SOAP or JMS call, querying SQL databases etc.</p> <h2>Comparisons</h2> @@ -73,13 +99,13 @@ <p>Jelly has various possible uses. Here's a few to think about</p> <ul> - <li>Alternative to Velocity & JSP</li> - <li>Page templating system</li> - <li>Code generation system</li> <li>SOAP, HTTP and/or JMS based scripting framework</li> + <li>A unit testing framework similar to Latka and AntEater</li> + <li>A workflow, EAI or integration, maybe integrated into commons-workflow</li> + <li>Page templating system</li> + <li>Code generation system, maybe an enhanced scripting engine for XDoclet</li> <li>Ant scripting</li> <li>Alternative implementation of JSTL</li> - <li>Enhanced scripting engine for XDoclet</li> </ul> </body> 1.5 +0 -4 jakarta-commons-sandbox/jelly/TODO.txt Index: TODO.txt =================================================================== RCS file: /home/cvs/jakarta-commons-sandbox/jelly/TODO.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- TODO.txt 15 Feb 2002 18:25:06 -0000 1.4 +++ TODO.txt 9 Mar 2002 15:32:10 -0000 1.5 @@ -1,10 +1,6 @@ TO DO LIST ========== -* introduce a config file on the classpath that describes the default URIs -> class names. - -* make 'body' a property of a Tag; then at the compile() stage a Tag can change its body if it wishes - or expand it etc. - * the org.apache.commons.jelly.impl package doesn't have a great name - can we think of a better one? also some of the classes in this package could maybe do with a rename? ScriptBlock for example - should we just call it a Block or maybe a CompositeScript?
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>