The animus expressed toward .XML style syntax is something that tends
to resonate with me. I do tend to like declarative approaches - which
both Ant and Maven more or less take - vs overly imperative approaches
to describing builds. Hence I tend to resist the temptation to take a
full blown scripting language approach to describing project builds.
As to another area where XML inflicts cognitive pain - Spring
Framework applicationContext.xml files.
I do believe in separating bean initialization away from compiled Java
code into a strictly interpreted-at-runtime text file of some kind. I
like a few annotations for some things but I don't want to use them to
fully replace the semantic actions that go on in
applicationContext.xml files.
I want a better bean configuration/initialization script language -
but not really an imperative language. I don't want to script logic
there, I just want to declare the initialization actions and the bean
relationships.
So hence I've grabbed ANTLR and am devising a new configuration DSL to
supplant XML. I'm calling it jfig. The syntax of jfig looks like this:
applicationContext.jfig
===============================================
properties_include "classpath:application.properties";
org.apache.commons.dbcp.BasicDataSource dataSource {
@destroy-method = close;
driverClassName = "${jdbc.driverClassName}";
url = "${jdbc.url}";
username = "${jdbc.username}";
password = "${jdbc.password}";
defaultAutoCommit = true;
}
org.springframework.orm.ibatis.SqlMapClientFactoryBean sqlMapClient {
configLocation = "classpath:sqlmap-config.xml";
dataSource = $dataSource;
}
java.util.Properties props {
"James Ward" = "Adobe Flex evangelist";
"Stu Stern" = "Gorilla Logic - Flex Monkey test automation";
Dilbert = "character in popular comic strip of same title";
}
java.util.HashMap map {
this($props);
}
===============================================
The '@' prefixes Spring BeanDefintion attributes that can be set.
The '$' prefixes bean ID names when they're being referenced as a
dependency.
Obviously includes for Java .properties definitions are supported and
use the ${foo.bar} syntax for referencing property definitions in any
bean configuration.
Notice the 'this' keyword is used when doing constructor injection (as
opposed to setter injection). Constructor injection can still be
combined with setter injection too.
The java.util.Properties class is specially recognized so that it's
easy to initialize an instance with name/value pairs, and then that
can be used to initialize other beans that accept a Properties
argument.
A certain amount of type checking will be done during jfig config file
parsing. If a bean class doesn't exist on the classpath, or a property
is not found, or is not of a compatible type (same with constructor
args), then will fail on the spot, referencing the relevant lines in
the jfig file.
Very early days. I've got a working parser that processes this syntax
and instantiates these beans. I'm next going to rewrite the parse
actions to start invoking Spring Framework APIs for bean definition
and bean registration.
Later on I'll use ANTLR to creat an ActionScript runtime in order to
devise a mini dependency injection framework for Flex apps - using
this same jfig syntax. It'll hold the AST in memory as the so-called
"application context". To instantiate a requested bean will involve
traversing the AST to instantiate dependencies in a just-in-time
manner.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
