tag:blogger.com,1999:blog-36547168.post7121317718645267923..comments2023-11-25T11:00:42.257+01:00Comments on Invisible to the eye: Factory for everythingGiorgiohttp://www.blogger.com/profile/03558287012747987157noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-36547168.post-10421494699294839192011-01-31T18:31:09.842+01:002011-01-31T18:31:09.842+01:00What a great web log. I spend hours on the net rea...What a great web log. I spend hours on the net reading blogs, about tons of various subjects. I have to first of all give praise to whoever created your theme and second of all to you for writing what i can only describe as an fabulous article. I honestly believe there is a skill to writing articles that only very few posses and honestly you got it. The combining of demonstrative and upper-class content is by all odds super rare with the astronomic amount of blogs on the cyberspace.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-36547168.post-82718596948612244952009-11-04T09:19:21.211+01:002009-11-04T09:19:21.211+01:00Of course you should ask! Discussion on this pract...Of course you should ask! Discussion on this practices is needed.<br />A DI container is in fact an automatically generated factory, but I prefer abstract factories since they are easier to configure.<br />Of course the main factory will be huge, but it contains only *new* operators so it's not a big problem. Maybe 100 lines of *new*s?<br />Beware that client objects require in the constructor only the collaborator, and not a factory. The factory instance the collaborators and injects them. No one has knowledge that exist a main factory. Decoupling from the collaborators *interfaces* is not possible as the client class depends on them.<br />I wrote about factories here:<br />http://giorgiosironi.blogspot.com/2009/10/object-oriented-myths.htmlGiorgiohttps://www.blogger.com/profile/12689416577856305650noreply@blogger.comtag:blogger.com,1999:blog-36547168.post-53893878212979444952009-11-04T06:35:35.491+01:002009-11-04T06:35:35.491+01:00So is the idea that there will be one factory for ...So is the idea that there will be one factory for the app that performs lots of tasks like this? <br /><br />This single factory functions as a kind-of DI container that creates/stores instances of my various services. <br /><br />Any client class that needs these services is passed the factory/container (probably in its constructor).<br /><br />Does that sound right?<br /><br />But then doesn't this factory/container get huge, encompassing all "service" creation?<br /><br />I understand the benefit of DI, but I always seem to get tripped up on notions of:<br /><br />1. Scope: where in my execution flow is my DI container actually instantiated), <br /><br />2. who gets passed what, and how much responsibility it should have. Should all clients classes accept my DI container as a constructor parameter, so all clients classes need to be DI-aware? <br /><br />Or should client constructors only receive the services that they need? In this case, the signature of the constructor is susceptible to change as we abstract/refactor service responsibilities.<br /><br />3. Size: if my factory/container is responsible for all my service creation, won't it get huge and unwieldy over time?<br /><br />Sorry for all the questions, but I feel like I am right on the edge of "getting" a lot of these compositional, loosely-coupled, DI concepts. But not yet quite there.<br /><br />Thanks and cheers,David Weinraubhttp://www.papayasoft.com/noreply@blogger.comtag:blogger.com,1999:blog-36547168.post-51834622003330829162009-11-03T14:20:23.328+01:002009-11-03T14:20:23.328+01:00Yes, I'm in a hurry now but it seems all right...Yes, I'm in a hurry now but it seems all right. If client code is in an object, it is not even aware of what factory is if you pass the factory in the constructor of your client (see Abstract Factory pattern). The benefits of this approach are independent testing of all the classes (besides the factory that contains only new operators and no logic to test).Giorgiohttps://www.blogger.com/profile/12689416577856305650noreply@blogger.comtag:blogger.com,1999:blog-36547168.post-79852864416312383722009-11-02T11:43:50.009+01:002009-11-02T11:43:50.009+01:00Hi Giorgio,
So the idea here is that inside My_Fa...Hi Giorgio,<br /><br />So the idea here is that inside My_Factory, the method createScaffoldingForm would look something like this:<br /><br />public function createScaffoldingForm<br />(Doctrine_Record $model)<br />{<br />$strategy = new Otk_Form_Doctrine_Strategy();<br /><br />$manager = new Otk_Form_Doctrine_OptionsManager();<br /><br />$form = new Otk_Form_Doctrine($model, $strategy, $manager);<br /><br />return $form;<br />}<br /><br />Then calling code - like an action controller - would use:<br /><br />$form = $myFactory->createScaffoldingForm ($model)<br /><br />Is that right?<br /><br />So controller code only sees the factory method, while inside the factory, you can create helper strategies, and managers, and gerbils on wheels. Client code is not aware.<br /><br />Is that right?David Weinraubhttp://www.papayasoft.com/noreply@blogger.comtag:blogger.com,1999:blog-36547168.post-73404024132253544742009-09-15T09:17:37.646+02:002009-09-15T09:17:37.646+02:00My solution relies on zend framework Zend_Form com...My solution relies on zend framework Zend_Form component which is highly coupled to Zend_View and other components to generate the html.Giorgiohttps://www.blogger.com/profile/12689416577856305650noreply@blogger.comtag:blogger.com,1999:blog-36547168.post-22302991168974767652009-09-15T08:41:27.976+02:002009-09-15T08:41:27.976+02:00Is there anyway of making form generation standalo...Is there anyway of making form generation standalone??Robson Loschihttps://www.blogger.com/profile/10228468171862171586noreply@blogger.comtag:blogger.com,1999:blog-36547168.post-166375320687422852009-09-15T00:13:57.325+02:002009-09-15T00:13:57.325+02:00My *experimental* work on generating form for Doct...My *experimental* work on generating form for Doctrine 1.x models is kept in the Ossigeno Cms subversion repository:<br />http://ossigeno.svn.sourceforge.net/viewvc/ossigeno/trunk/core/library/Otk/<br />The main point was distinguish between relationship towards entities, which use a select or multiselect, and relationship towards value objects which use Zend_SubForms.<br />It's an open source product, so feel free to do nearly whatever you want with it :)Giorgiohttps://www.blogger.com/profile/12689416577856305650noreply@blogger.comtag:blogger.com,1999:blog-36547168.post-28686607953407572082009-09-14T23:32:38.535+02:002009-09-14T23:32:38.535+02:00Hey, man.
I didn't find a link to download and...Hey, man.<br />I didn't find a link to download and test your class. Does it exist??<br />A couple of months ago, I was working on a class called "DocForms" that could generate forms based on doctrine models but I stopped it development when I had trouble with relationships.Robson Loschihttps://www.blogger.com/profile/10228468171862171586noreply@blogger.com