Patches to allow factories
Dolf Starreveld
In making the conversion I ran into two issues that stood in the way of rapid progress:
1) My legacy code depended on several factories to create what SF calls "services". The factories provided the rest of the code a level of independence from details, but I could not find a way to use these factories in the SF XML format. I'd rather not have to write a tremendous amount of new code. I prefer step by step modification of code to do such kind of refactorings.
2) I had large amounts of XML configuration assuming the Zend_Config_Xml format.
To ease the process I developed patches for the latest 1.4.x DI code to address each issue.
The factory approach was enabled by modifying the relevant files to allow something like this:
<service id="Layout" constructor="factory">
<factory service="bootstrap" method="getPluginResourceFromClass">
<argument>ExpandedLayout</argument>
<argument type="collection">
...
</argument>
</factory>
</service>
As you can see a new kind of "constructor" called "factor" is introduced. Factories must be other services and the <factory> element behaves virtually identical to <call> except that it allows specification of another service whose named method is to be called. The other difference is that the result of the call is expected to be the constructed object. Off course the xsd file was also modified to accommodate this.
The second issue was addressed by change allowing this:
<argument type="xml">
<xml type="zend">
<roles>
<guest value="" />
<user>
<inherit value="guest" />
</user>
</roles>
</xml>
</argument>
This allows incorporation of arbitrary XML in inside the <xml> tag. The "type" attribute tells it to read it into an array produced by Zend_Config_Xml. Future values could be added if other kinds of interpretation are needed. This particular modification was just a convenience one. It is certainly possible to rewrite a Zend_Config_Xml into the correct format (and it could even be automated).
I modified the PHP dumper to deal with both issues and produce correct output (I love this feature, it makes the container processing nearly cost free!).
So here is my question:
- Is there any interest in these patches?
- If not, what would be the reasons you think these are a bad idea?
- If so, how can I best contribute them? At the moment I am not in a position to become a developer and commit directly to SVN.
Fabien Potencier
> As a heavy user of Zend Framework I wanted to integrate the dependency injection component instead of the Zend provided container. The obvious benefit would be a transition to on demand object (service) creation, where Zend kind of forces them all to be created at startup time. Before I started this effort I had legacy code from before ZF 1.9 so I did not even use the new(er) bootstrapping framework.
>
> In making the conversion I ran into two issues that stood in the way of rapid progress:
> 1) My legacy code depended on several factories to create what SF calls "services". The factories provided the rest of the code a level of independence from details, but I could not find a way to use these factories in the SF XML format. I'd rather not have to write a tremendous amount of new code. I prefer step by step modification of code to do such kind of refactorings.
> 2) I had large amounts of XML configuration assuming the Zend_Config_Xml format.
>
> To ease the process I developed patches for the latest 1.4.x DI code to address each issue.
> The factory approach was enabled by modifying the relevant files to allow something like this:
>
> <service id="Layout" constructor="factory">
> <factory service="bootstrap" method="getPluginResourceFromClass">
> <argument>ExpandedLayout</argument>
> <argument type="collection">
> ...
> </argument>
> </factory>
> </service>
>
> As you can see a new kind of "constructor" called "factor" is introduced. Factories must be other services and the<factory> element behaves virtually identical to<call> except that it allows specification of another service whose named method is to be called. The other difference is that the result of the call is expected to be the constructed object. Off course the xsd file was also modified to accommodate this.
I need to think a bit about this one. I like the DI container because of
it's relative simplicity. So, before adding any new construct, I'd like
to think about it a bit more and see if there is not another way of
doing it.
>
> The second issue was addressed by change allowing this:
> <argument type="xml">
> <xml type="zend">
> <roles>
> <guest value="" />
> <user>
> <inherit value="guest" />
> </user>
> </roles>
> </xml>
> </argument>
>
> This allows incorporation of arbitrary XML in inside the<xml> tag. The "type" attribute tells it to read it into an array produced by Zend_Config_Xml. Future values could be added if other kinds of interpretation are needed. This particular modification was just a convenience one. It is certainly possible to rewrite a Zend_Config_Xml into the correct format (and it could even be automated).
I think this one is indeed a good idea.
>
> I modified the PHP dumper to deal with both issues and produce correct output (I love this feature, it makes the container processing nearly cost free!).
>
> So here is my question:
> - Is there any interest in these patches?
Yes, sure
> - If not, what would be the reasons you think these are a bad idea?
> - If so, how can I best contribute them? At the moment I am not in a position to become a developer and commit directly to SVN.
The best way is to create a ticket on the symfony trac:
http://trac.symfony-project.org/
and to attach the patches so that I can review them and merged them into
the trunk.
Thanks,
Fabien
>
> --
>
> You received this message because you are subscribed to the Google Groups "Symfony Components" group.
> To post to this group, send email to symfony-c...@googlegroups.com.
> To unsubscribe from this group, send email to symfony-compone...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/symfony-components?hl=en.
>
>
>