Okay, that settles it for me. I'll wait. Thanks.

“Slitting your own throat here?” Heh... That's why we invest our time here. “Blunt professional honesty = Priceless.”

And... lest anyone from the Reaction group think that this is “a negative reaction” ... I think that it is quite fair to say:

• Rome was not built in a day... neither was anything else on CPAN. “We can wait!”
• “We shall make no wine before its time.”
• Meanwhile, we all have customers to serve.   :-D

I, like you, am very interested in Reaction (and based on my code-reading this evening, I am...), and willing to wait-a-bit for its maturity. I see now that I don't have to “shut the door on” using it effectively within the scope of even this project. To leap onto this bandwagon prematurely ... is quite unnecessary.

Thanks again.

Being the project lead clwolfe refers to above, allow me to diatribe my view:

To fully take advantage of Reaction one needs solid working knowledge of Catalyst, M(F)CV pattern, OO, Moose, and most likely an ORM such as DBIC. These skills don't come overnight or a even in a fortnight, but for me me they are valuable skills to seek.

IMHO, Reaction breaks an application into more than just the three traditional parts of the MVC design pattern. For instance, it requires splitting the model into two parts: business domain and an interface between the business domains and the controllers/views. The views divided into widgets and layout (nested containers for the widgets). In a simpleton's world you may say Reaction carves the app up into 5 or more parts.

It is true that Reaction is in an early stage and the documentation is growing from sparse to better, but needs community help. What isn't true is the claim that I was talked into using Reaction. It was a choice I made based on a number factors, some better than others:

* The success I had with mst's perl contributions, even modules at early version numbers.
* The idea of diversifying the model into multiple components.
* Being involved with an open source project at an earlier stage.
* Securing the interest of busy consultants to help us with a substantial project with very short turn-around time.
* Expand my comfort zone
* Move away from homegrown components of a framework to standard libraries, or at least libraries being standardized.

One can see that there was some risk involved being an earlier adopter, but the project did not come in late. In fact we achieved one of the few major deadlines in the entire contract so far. Did we get on each other nerves some in the process, hells yes. Did we have reduced functionality? I would say not. What we had was the (I should have known) moving of the goalposts. Do we need such and such feature (from previous system we were redesigning in similar but not exact business domain)? The answer would be no at first then change to yes in midstream of a super-tight deadline. We delivered all the original functionality and more on time. We hadn't planned on scrapping the whole data model we were forking from a similar project, but at the last hour possible we did. That created the most stress, but that data model change from the old cankerous model to the intelligent design model has been a builder's stone worth creation. Changing the data model allowed the the whole application to coalesce using Reaction libraries and Catalyst in short time, and it smoothed the way for data population and computation.

Reaction is definitely not for everybody, and it probably isn't but for the minority of perl web app. devs, but it is a vital project that delivered a solid application for us on time. If you are comfortable with Catalyst or another M(F)CV and would like to enrich that experience then Reaction is definitely worth investigating.

Docs may not abound, but there are some examples and I be willing share our code with anyone interested. Reaction evolves quicker with action not words.