Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
We should look into providing a tool than reads source code and looks at the names of parameters to constructors. These names are the names of instances registered in Pico. Therefore no need for any external meta data.
e.g.
public class EmailService(Datasource source1, Datasource source2) {
}
Run this through the "source parser" and you get out a resource bundle that states that EmailService needs a Datasource called "source1" and another called "source2".
Write a particular NanoContainer that operates off this resource bundle and registers the components accordingly.
Activity
This idea can be extended to include the names of all dependencies, i.e. other components and parameters. So if you write this:
public class EmailService {
public EmailService(Datasource source1, Datasource source2, String emailServer, int emailPort, String another, String oneMore) {
}
}
Then this registration XML covers it:
<component name="source1" type="Datasource" class="DatasourceImpl"/>
<component name="source2" type="Datasource" class="DatasourceImpl"/>
<component type="EmailService" class="EmailServiceImpl">
<emailPort>21</emailPort>
<emailServer>smtp.yahoo.com</emailServer>
<oneMore>blah</oneMore>
<another>blah blah</another>
</component>
So there is no "wiring up" metadata - just a declaration of whats available, Pico does the rest.
Mike Hogan
added a comment - This idea can be extended to include the names of all dependencies, i.e. other components and parameters . So if you write this:
public class EmailService {
public EmailService(Datasource source1, Datasource source2, String emailServer, int emailPort, String another, String oneMore) {
}
}
Then this registration XML covers it:
<component name="source1" type="Datasource" class="DatasourceImpl"/>
<component name="source2" type="Datasource" class="DatasourceImpl"/>
<component type="EmailService" class="EmailServiceImpl">
<emailPort>21</emailPort>
<emailServer>smtp.yahoo.com</emailServer>
<oneMore>blah</oneMore>
<another>blah blah</another>
</component>
So there is no "wiring up" metadata - just a declaration of whats available, Pico does the rest. Does someone want to have a go at this one? Otherwise I'll close it as "Won't fix". (Seems a bit bell and whistly to me).
Aslak Hellesøy
added a comment - Does someone want to have a go at this one? Otherwise I'll close it as "Won't fix". (Seems a bit bell and whistly to me). Aslak Hellesøy
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Mike Hogan [ m081072 ] |
My preference is not to do this. I can't help feeling there are other ways to do the same.
Paul Hammant
added a comment - My preference is not to do this. I can't help feeling there are other ways to do the same. Feel free to implent this functionality in a new picoextras subproject if needed.
Aslak Hellesøy
added a comment - Feel free to implent this functionality in a new picoextras subproject if needed. Aslak Hellesøy
made changes -
| Resolution | Won't Fix [ 2 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
QDox is the perfect tool for this