You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hivemind.apache.org by hi...@jakarta.apache.org on 2004/05/04 05:49:33 UTC

[Jakarta HiveMind Wiki] Updated: NotXMLProposal

   Date: 2004-05-03T20:49:33
   Editor: HarishKrishnaswamy <hk...@comcast.net>
   Wiki: Jakarta HiveMind Wiki
   Page: NotXMLProposal
   URL: http://wiki.apache.org/jakarta-hivemind/NotXMLProposal

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -188,3 +188,115 @@
 ChristianEssl: XML is for me. If I look at the tremendous work Howard has put into the XMLParser I'd say a JavaCC grammar would be even easier for !HiveMind - less validation. XML is for me because I somehow got to know what an element and an attribute is, how to start and end the document, how to escape things, how to add comments, the meaning of whitespace, what are valid names, knowing which block-close belongs to which start without a lot of counting and finally knowing that others know that (and certainly much more) too. Apart of this looking at the example Harish gave I think he actually meant an language whith only expression-instructions. Well that's not everyones taste, but I'd call it declarative and line pricese reporting can be maintained this way. It has the advantage that it's relatively easy to use combined with !JavaDoc. Further it would be very easy to implement convinience methods.   
 
 HowardLewisShip: ["JavaCC"] generates a token stream and each token knows it start and end line number and column. I think it will be much easier to support this than with XML. I suspect we'll be able to easily get that information out of the parser and into the plugin. Like Tapestry, a plugin shouldn't be all that necessary ... the SDL stuff takes the teeth out of XML, making it look quite pleasant.
+
+HarishKrishnaswamy: Ok, here's a little more elaborate example.
+{{{
+/**
+ * Service point definition
+ */
+servicePoint("service-id", ServiceInterface.class);
+
+/**
+ * Singleton service constructed via constructor injection
+ */
+singleton
+(
+    implementation
+    (
+        "service-id", 
+        ServiceImplementation.class, 
+        new Object[] {1.34, "some string", service("some-service-id")} // constructor arguments
+    )
+);
+
+/**
+ * Pooled service constructed via setter injection
+ */
+dependencies = new HashMap();
+dependencies.put("property1", property1Value);
+dependencies.put("anotherService", service("anotherServiceId"));
+
+pooled
+(
+    implementation
+    (
+        "service-id", 
+        ServiceImplementation.class, 
+        dependencies // Setter arguments
+    )
+);
+}}}
+
+This file will be read and built by a builder class that will look something like this:
+{{{
+public class BshBuilder
+{
+    ...
+    public void buildModule(URL moduleUrl, Registry registry)
+    {
+        try
+        {
+            Interpreter interpreter = new Interpreter();
+    
+            interpreter.set("$helper$", new BshBuilderHelper(registry));
+    
+            interpreter.eval("importObject($helper$)");  // This is a mixin command
+    
+            interpreter.eval("importCommands(\"path/to/evalModule.bsh\")");
+    
+            interpreter.set("$interpreter$", interpreter);
+            interpreter.set("$callstack$", new CallStack(interpreter.getNameSpace()));
+
+            registry.setCurrentModuleName(moduleUrl.toString());
+
+            interpreter.set("$url$", moduleUrl);
+            interpreter.eval("evalModule($url$, $helper$, $interpreter$, $callstack$)");
+        }
+        catch (Exception e)
+        {
+            handleInterpreterException(e);
+        }
+    }
+    ...
+}
+}}}
+
+evalModule.bsh is the same script that I had posted previously. The BshBuilderHelper will look something like this:
+{{{
+public class BshBuilderHelper
+{
+    ...
+    String _currentModuleName;
+    int    _currentLineNumber;
+
+    public void servicePoint(String serviceId, Class serviceInterface)
+    {
+        Location location = new Location(_currentModuleName, _currentLineNumber);
+        // Register the service point with the location
+    }
+
+    public Object implementation(String serviceId, Class serviceImplementation, Object[] constructorArgs)
+    {
+        Location location = new Location(_currentModuleName, _currentLineNumber);
+        // Register the service implementation with the location
+        return service;
+    }
+    
+    public Object service(String serviceId)
+    {
+        // Get service
+        return service;
+    }
+    
+    public Object singleton(Object service)
+    {
+        // Make service a singleton
+        return service;
+    }
+    ...
+}
+}}}
+
+BshBuilder receives the module descriptor sets up the BeanShell interpreter by mixing in the BshBuilderHelper object and executes the evalModule script. The evalModule script reads the module descriptor one statement at a time, sets the line number of the executing node in the helper, and executes it. The helper does the needful. And that's pretty much all for handling the descriptors.
+
+Of late, I have really subscribed into KISS and [http://martinfowler.com/bliki/EnablingAttitude.html Enabling Attitude] principles and these ideas are simply a repercussion of that.

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org