Very cool, Roger. If people are interested in seeing similar ideas that have been in production deployments for years (and had most of the the corner-cases smoothed out), there's the BeanBuilder from Grails (can be used stand-alone) and Spring JavaConfig. The BeanBuilder is great for its terseness and looks very similar to jfig in syntax. JavaConfig is for the "Dang-it, I'm a Java programmer! I don't like XML, want the benefits of static typing, want the benefits of external configuration, but don't want to do any more work than absolutely necessary."
http://grails.org/Spring+Bean+Builder http://www.springsource.org/javaconfig On Wed, Nov 26, 2008 at 2:25 PM, RogerV <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
