Details
-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.3
-
Fix Version/s: 2.0
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Testcase included:yes
-
Number of attachments :
Description
Once in a while with Pico, my hands cramp up writing the compositions. pico.registerComponentImplementation() just starts getting long after the 20th or 30th time
I like the Groovy Builder syntax for its brevity and wanted to see something similar available for Pico in pure Java code.
So today I created a basic interface that while not quite as flexible as Pico's core API, it is really darn convenient. It simply sits aside PicoContainer, no changes in the core API necessary.
Example Usage (More in javadocs in patch)
MutablePicoContainer pico = new DefaultPicoBuilder() .component(ArrayList.class) .instance("This is a test") .component(ServiceOneInterface.class, ServiceOne.class) .component(ServiceTwo.class, ServiceTwo.class, new Parameter[] {....}) .build(); assertEquals("This is a test", pico.getComponentInstance(String.class);
The real limitation with this method is that it doesn't return the component adapter, so you can't find tune the component adapters during the build. (I basically mirrored the MutablePico API otherwise). But since build() doesn't call any lifecycles, you can have:
MutablePicoContainer pico = new DefaultPicoBuilder().instance("test").build(); ComponentAdapter ca = pico.getComponentAdapter(String.class)
Again, my goal was to save typing, but I believe this could get very handy.
What do you guys think?
-Mike (R)
Activity
Field | Original Value | New Value |
---|---|---|
Status | Open [ 1 ] | In Progress [ 3 ] |
Fix Version/s | 1.3 [ 11331 ] | |
Fix Version/s | 2.0 [ 10411 ] |
Assignee | Michael Rimov [ rimovm ] | Paul Hammant [ paul ] |
Status | In Progress [ 3 ] | Closed [ 6 ] |
Resolution | Fixed [ 1 ] |
Looks fort me a perfect match for the o.p.gems.util package. WDYT?