DI didn‘t invent ‘The Hollywood Principle.‘ So don‘t call me, I‘ll call you. Yeah that‘s great. That tells us that the container will compose the context, but is that it? The context itself is still just whatever all you need at any given time to do some unspecified amount of work.

Last week, we were finishing some logic in a 4 or 5 panel wizard that required us to resubmit orders many times. (You‘ve seen this movie before..) The restart was nothing, I was actually enjoying that part. Watching my pair partner fill out the registration like 50x made me completely crazy. While I was in the sidecar, I started thinking about an escape valve…

One of the great things about JSF is that the binding is pretty straightforward, and the framework does a lot of the other work (marshal/unmarshal, convert/validate, etc.) So it dawned on me that all I really needed was a way to stipulate a different factory for the abstraction that the wizard was binding, and then I would feed up an instance with the fields filled out so we could just click through the panels. Here‘s the sick part: a decade into the DI revolution, that‘s not only not a simple thing to do, it‘s dizzyingly stupid how much flapping is required to get this emu off the ground.

Checkout this blog post . There‘s nothing wrong with it, it‘s pretty interesting and the author seems to be pretty excited about it, but dear god, all the crap that is needed to sneak an alternate implementation is really nauseating.

While I was scouting around for the right way to do this with CDI, I mentioned this to mert, and he mentioned that JSF2 has stages. Of course ended up on the Adam Schwartz blog post I‘ve seen 20x. Sounds cool, or looks cool, but that‘s not going to do what I need, it might make it easy. Took some humor in the fact that Matthias wanted to make a system property out of it; kind of typified the madness at the center of this: the bean container wants to give you declarative powers, then the annotations take them back and put them back into compile time realm, ultimately, all this time later, the central trope here (Liskov‘s substitution principle slubbed through the usual DP slats: prototype, singleton, etc.) is still unable to bridge this gap easily.

How should this work? I guess what I am thinking about doing now is making a listener on the container start, then looking at the hostname. If it‘s localhost, I would light up a bunch of Development factories. How? I‘d probably have to do some goofy interceptor-based substituter like in the blog post, which is total madness, but of course, we don‘t want the code annotated with a bunch of development requirements that have nothing to do with the model. What would be best would be if the concept of context was a bit more sophisticated. Not a jumble of chained black magic like the classloader mechanism, but if there were a way to define the contexts that are nested, and triggered by certain environmental conditions, then the factories associated with those contexts would naturally just come to the fore.

Update: Starting to look like what I‘ll do is look for the hostname and then trigger a method if it is localhost that will allow me to load anything I want to into a development environment (kind of like a PostConstruct) but using AfterBeanDiscovery.addBean() with an Alternative. I had thought one other possibility might have been to make an @Alternative implementation of the abstraction that also had a qualifier on it that would not be true (and hence would prevent the alternative from being loaded if we were not in a dev environment).

 

From http://www.jroller.com/robwilliams/entry/contexts_decade_in