LightWire Preso Recording Available Online
As Nick just mentioned, the LightWire recording is now available online.
The presentation provided a brief intro to Dependency Injection, a short overview of ColdSpring and then ran through how to use LightWire and why you might consider it for some use cases.
If you're interested in why you might want to use a programmatic config file, "mixin injection" or "ghetto annotations", check it out. Good Q&A at the end, and as always, Joe had the last word (ColdSpring Forever *grin*).
Anyway, I thought I had copy and pasted one of his last questions which /really/ made me think, but I can't seem to find it. It is near the end and I'll look it up tommorrow.
Then Joe R. had a good question too, which I thought you addressed well, but may be worth writing down and addressing the goop =)...
I think what people need to understand, though you said it repeatedly, is that LW supports BOTH programmatic and XML configs and it also supports BOTH setter and mixin injections. If for some reason you want to write (or generate, maintenance will still be a chore though) all that XML they are free to do so. If you think that methods should clutter your API for documentation then use setter injection, it is your choice. What should not be overlooked (through all these fueled words) is that LW supports BOTH!
Borracho did raise a good question, though I think it was based on another misunderstanding. Basically, he asked if instantiating the config bean and the LW bean in the application creates tight coupling between the application framework and the DI/ioC framework. At least, that is if he understood LW correctly and I understood his question. Here is what he actually wrote:
"To me, programatic confiruation in application code represents a new dependency in your application, and also very much degrates the concept or IoC, as we are actually now returning the control of component configuration BACK where we were trying to remove it from."
Joe responded by saying that LW "inverts inversion and and places concrete type references back in the code."
Could you comment about this?
TTL,
Aaron
P.S. Didn't Hal Helms term the word "Mixins" or was the Mixins he referred to in his duck typing preso something altogether different?
@Aaron, A config file is fundamentally dependent on a tool capable of understanding its format. If you don't think a CS app has any ColdSpring dependencies, try deleting ColdSpring from the server and running the app. Right now the benefit of using an XML file is that both LightWire and ColdSpring support the same file so if you wanted to move between the two you could do so. Because CS doesn't currently support programmatic config, you can't use a LightWire programmatic config in ColdSpring, but I don't see that as a big problem.
The issue of removing coupling with DI is stopping all of your beans from having to explicitly call a getBean() method on a factory for every bean they need. Both ColdSpring and LightWire achieve that and they achieve it in the same way - via dependency injection.
Joe was right and wrong - but in the end it is a meaningless comment. It assumes XML is this magic stuff and code is not. XML is a form of programming. It is a form of programming that is usually based on a limited syntax without looping and other control constructs (you can describe those in XML but most people don't). Somewhere you have to document your beans dependencies. I'd rather do it in 100 lines of programmatic config than 10,000 lines of XML, but to each their own!
Hal was probably the first person to talk about Mixins in the CF world, but they have a much longer history than that in other languages.
Thanks for the comments guys!
XML is a form of programming?? WTF?
XPath may be, XSL certainly is, but XML itself is structure, not programming. It may be based on a schema, it may be a document format, and the config file is full of content, but it's certainly NOT programming. It's syntax and structure and content.
I've never seen an application using ColdSpring that uses 10,000 lines of XML for anything. If you've got that much XML for your application config, I think perhaps either you have a massive, massive application or it's time to fundamentally revise your architecture.
I agree with Peter - XML can be thought of as data or logic, just like your code can be thought of as data or logic. I see no fundamental semantic difference between writing inject(bean=someBean, into=anotherBean) and <inject><bean>someBean</bean><recipient>anotherBean</recipient></inject> except that the way I'd prefer to do it has decidedly less clutter.
I'm sure 10,000 lines is an exageration, but when I wrote the XML for my demo for what I'd consider a fairly small app (25 business objects which maps to 125 beans) without my controller facade, custom data type, rendering or core framework beans I knew that I'd rather have 40 lines with a control loop.
If you're that hell bent on not using code, why not just manually write HTML pages for your commerce stores instead of using templates and cfoutput - it's the same thing - level of abstraction higher.
Now, since you're hell-bent on comparing LightWire to ColdSpring, all you'd have needed to do was implement a ProgrammaticXmlBeanLoader.cfc that extended the abstract bean loader that comes with CS and is the base class for the DefaultXmlBeanLoader class used to read these extremely verbose and laborious XML config files.
Also, ColdSpring includes AOP (one of the most powerful tools for integrating exsiting models with remoting clients there is), Parent Factories, factory-bean/factory-method (which would work perfectly for instantiating transient objects, incidentally), and a whole host of features that you regularly leave out of your presentations. If you're going to be bringing up ColdSpring, would you please start engaging in full disclosure about what CS is/does before you go on about how much better LightWire is? The fact that you keep on about how "well yeah, CS does this, but LightWire DOES THIS! W00T!" is misleading to the public and insulting to ColdSpring's developers.
Furthermore, I don't see a "config file" in any of your recent posts, I see some custom loader CFCs, but these aren't "config files" in the classic sense, and maybe that's where I'm getting hung up. I'm still unsure of what you mean by "programmatic config file" because I see you using custom one-off CFCs that would more accurately referred to as "DirectoryParsingBeanLoaders". They've got nothing to do with config and everything to do with parsing directories and loading up instances based on them. The way I've always seend things done is this: a config file contains user-supplied values that the framework uses to make decisions and take actions. A DirectoryParsingBeanLoader contains code that you wrote to read the contents of a directory and instantiate bean instances based thereon.
Maybe I really AM backward and provincial and don't know Lisp, but I DO know the difference between a config file and a code library.
Not suggesting country bumpkin (dude I've met you - I know how smart you are!) - but you thinking I was crazy for suggesting that XML might be a programming language - just annoyed me. It'd be like someone who hadn't programmed in or researched CF thinks you're crazy for suggesting it could have any benefits over Java. Apologies again.
The only reason I compare LW to CS is to focus on the different approaches to some problems. In the LightWire preso I gave, one of the first slides was "Why ColdSpring" and suggested some of the reasons for choosing ColdSpring over LightWire including the fact that it is more mature, has a bigger developer community, has great documentation at the website and includes remote bean proxies and AOP one of which LW won't and the other of which (AOP) I haven't had a need for in my SPL but is on the "whenever I get a free weekend" list.
I think framework authors have a responsibility to answer a basic question which all developers have - when should I use X compared to Y. Obviously the authors of different frameworks will have different opinions on that, but I'm looking forward to Matts upcoming comparison of MG and M2 and hopefully a similar document from Joe so we at least have some thoughtful comparisons from the people who know best so we don't have to give the crappy cop out answer of "try both then decide" whenever someone is trying to figure out what framework to use.
> whenever someone is trying to figure out what framework to use.
"Try both then decide" is a really responsible answer to that question. No app should be so bound to a framework that you can't try both quickly. Substituting someone's own experience and judgement with what amounts to marketing spin (none of us can be completely impartial - not necessarily from personal prejudice, but simply because we won't know framework B as well as one we've written) from a framework author is a poor tradeoff.
XML, in and of itself, is simply a nested set of containers... saying XML is a programming language is like saying Tupperware is a refrigeration system. It's data and metadata, it's structured data, fine, all true, but until you introduce something capable of some sort of runtime handling on it, it's not a programming language.
Again, XSL is, fine, fair enough. XPath and XQuery might be, depending on your approach, and you can certainly use XML to define some syntax (aka "vocabulary") that some other system may be able to do processing against, but calling XML a programming language is like calling a gas can an oil refinery, like calling paper a printing press, or like calling a paint brush an artist. XML might be part of a programming language, might define the a syntax or vocabulary of directives which some interpreter is capable of processing, but saying "XML is a programming language" is as blatantly incorrect as any of the examples I've given thus far.
And YOU are far too smart to have missed that, so what's the deal?
You can read Consumer Reports all you want, but that's no replacement for test driving your top 3 choices for your new car. Nothing replaces personal experience and nothing can reveal the strengths or weaknesses of a relationship between you and a platform like personal experience.
Case in point: I can't fit in an Audi TT... I'm too big. It's not a bad car by any means, in fact I think they look cool, but I wouldn't have known I couldn't fit in one and hence would never own one until I actually tried to.
I hope that nobody expects a framework author to be impartial. I think it is reasonably that a framework author try to be open to the strengths and weaknesses of their framework and to document those to the best of their ability. I just can't believe that if I read a detailed thoughtful comparison of MG and M2 bu yourself and another from Matt that I'd be less capable of making a decision than if I didn't. Clearly working with a framework deeply is better than a naturally biased perspective, but I'd bet money that I'd learn something from your and Matts documents that'd give me a head start on selecting a framework, a couple of subtle or even show stopper pointers that'd help deciding for a specific use case.
I understand that the costs of switching between MVC frameworks is fairly low, but it is important not to generalize that concept. It'd be a darn site more work to port a Rails app to Camping - the ore a framework does (and helps) the less portable your code is between framworks - not right or wrong, just another engineering trade off.
Good to know about the Audi - I'll make sure to test drive ONCE I've read consumer reports :->
You can read Consumer Reports all you want, quote performance stats and have a veritable intellectual library available, but until you actually do it yourself, that's all pretty meaningless. The point of the Audi example was just that: it's a great car, good stats, by all accounts perfect for me... until *I* went and sat in one, or tried to, and the whole idea went POOF.
Same with frameworks... these Consumer Reports-style statements mean nothing without the personal experience to know if it fits.
addSingleton("com.my.Bean", "Bean"); is data.
<bean id="Bean" class="com.my.Bean"> is data
Neither of them do anything on their own. They are both just expressions of intent. In fact they are just two different representations of the same intent and if you wanted to it'd be fairly straightforward to transilterate between them automatically.
Both of them are programming because they are statements of intent that affect the execution of a program.
The truth is that there is no black and white line between data and programming. XML is a syntax for expressing intent as is free form text or a record in a db.
Man . . . I wanted to finish this up, but clients are driving me nuts. Gotta go do some paying work and eat before Cambridge shuts down for the night. Lets catch this later because it probably sounds pedantic right now, but it is a really interesting debate that opens up some cool possibilities.
In short, EVERYTHING can be looked at as a language - an API and an XML schema are both expressions of a specific abstract grammar and both are domain specific (but not necessarily turing complete) languages.
To be continued some time . . .
Honestly in the case of audio, I'd RATHER read consumer reports or Audio Magazine or whatever as they probably have a keener ear. Honestly do you think someone who is starting with OO and doesn't know a DAO from a Service class is going to get all of the subtle distinctions between frameworks without any comparitive information?
It is like religion. By all means read the Quo'ran and the Bible, but that doesn't mean there is no place for comparative Religion. Sometimes even opinions help!
It's very easy to get out on thin ice if you try to compare two "products" that ostenstibly do similar things. Look at the heat generated around any CFMX/BD discussion that attempts to compare the two...
My position is that "programmatic configuration" is code and I don't want my configuration in code. I want my configuration to be non-executable. I want a clear dividing line between code and non-code. Code executes, non-code (data) does not execute. Your "programmatic configuration" IS code and it DOES execute. XML is NOT code and it does NOT execute. No amount of weasel-wording can change that.
Yes, the line is extremely blurred in LISP because data is represented using the same notation as code and therefore programs can be treated as data (the reverse is not true: (a 1) is not a valid lisp program... unless of course 'a' is defined as a function :)
Got to disagree a little. XML is just a different concrete syntax.
addbean("com.whatever");
and
<Bean class="com.whatever" />
are clearly both identical. Are they data or code? I'm not sure but because they are communicating exactly the same thing if one is code they both are and if one is data the other is. Lisp teaches the point well, but the underlying fact is true here as well.
Now, if you compare the following, I start to agree with you:
For Each(businessobject in BusinessObjectList)
addBean(BusinessObject);
Next
to
<Bean class="com.Product" />
<Bean class="com.Article" />
<Bean class="com.Category" />
then there clearly is a difference and for them to be identical you'd have to add a loop construct to your DTD (which you could do)
<ForEach itemName="BusinessObject" List="$BusinessObjectList">
<Bean class="BusinessObject" />
</ForEach>
I agree that both the XML AND non-XML representations with the concept of a control loop are fundamentally different from the XML without the control loop and if I was to make a distinction between programming and config data it would be on whether the collection of statements included control loops or conditionals. Things get a little more interesting when you try to determine whether the concept of variables or functions are a necessary condition for something to be called code, but I'm not interested enough in the distinction to take a position on those either way.
I think there are arguments both for and against writing configuration information in a language (any statement parsed by the computer - whether "data" or "code" can be seen as a statement in a Language - DSL - it is just that some of them aren't Turing complete) that supports control structures. The obvious benefits of a programmatic config is that for repetitive information it is more concise. In CF the compile cycle isn't an issue (of course it isn't an issue in Java any more - you just write your programmatic configs in a scripting language like Groovy). There are valid reasons for not using a programmatic config (both absolute and in terms of preference), but they don't apply to my use case so I'll save the keystrokes to keep posting about DSLs and the like on my blog instead of entering repetitive information into XML configs.
(Informed) choice is good :->
"Once you decouble grammar from syntax you can make much tighter decisions about the best ways to solve a specific use case" .... one of the most useful notions I've absorbed in a while....great sentance.
stigg
In a nutshell: I think it depends on the intent, and in this case, I think it is.
@Sam, Cool posting - thanks.