Date: 2004-05-03T20:49:33
Editor: HarishKrishnaswamy <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
