The thing about this metadata config language is that I wanted to stay
with runtime interpreted text file approach. I didn't want to compile
anything into a .class file just because a tweak needs to be made in
the applicationContext file. And I do like the approach of entirely
externalizing bean metadata configuration ala applicationContext.xml.
I just want a much better syntax than the xml stuff that Spring
conjured up, and I want the syntax to be specifically geared to the
needs of declarative data initialization and dependency referencing.
No more - no less. A true DSL approach, IOW. Using Java invites too
much of an imperative programming approach.
Also, I'm okay with a very occasional annotation sprinkled into the
application Java source code, such as:
@ContextConfiguration(locations = { "/applicationContext.xml" })
or
@Autowird private SqlMapClient sqlMapClient;
But I don't want to deep dive into a heavy use of annotations. It
would then begin to be pollution - like much C# .NET code, which is
often heavily ridden with annotations. And especially don't want to
use annotations in a manner that should be better expressed in an
externalized configuration file, ala applicationContext.xml, i.e., the
Guice problem.
As to the Grails/Groovy BeanBuilder approach - in the past I've been
an advocate of using Groovy to do this and have lobbied Rod Johnson
about it directly. Is true the fig/jfig syntax and BeanBuilder syntax
are fairly similar in some respects.
In my case the middle-tier stack will have Spring Framework, but not
Grails or Groovy. Some would say simply add those. For various reasons
that's not going to happen yet. For our production sites we've not
fundamentally embraced Groovy or scripting languages into the mix.
Also, as expressed in the original posting, I want to keep the
metadata configuration strictly declarative in nature. Groovy would
invite the temptation to start scripting the metadata configuration,
which then invites the potential for bugs and QA. I don't want the
metadata config portion of the application to ever become code in that
sense. I want it to fundamentally remain declarative data. (I also
like very streamlined solutions with the most minimal runtimes
necessary to accomplish the goal - just an aesthetic thing. Fewer
moving parts fewer things to go wrong.)
Also, my longterm goal is to have a consistent jfig metadata config
language to use for both the Java middle-tier and the Flex client-
tier. Neither of these other two choices would accomadate that.
But hey, there's nothing wrong with more choices being available for
how Spring Framework metadata gets configured. It's nice to finally
see the wealth of choices.
On Nov 26, 1:08 pm, "Jim Moore" <[EMAIL PROTECTED]> wrote:
> 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
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
