This posting was motivated by another forum discussion topic where angst toward XML was one of the themes:
Java builds (maven, ant), the java way is broken! http://groups.google.com/group/javaposse/t/80791272eaa49d03 What I express below regarding the jfig language syntax and basic idea, is an extension of what ANTLR creator, Terence Parr, posted on the web, and which he dubbed 'fig': Fig - Generic configuration language interpreter http://www.antlr.org/wiki/display/ANTLR3/Fig+-+Generic+configuration+language+interpreter Terence didn't take this very far - just enough to illustrate the concept and to spur others to take it on further - which is what I am doing with jfig. :-) Now to the meat of this particular posting: 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 dependency 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's 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 -~----------~----~----~----~------~----~------~--~---
