Coolio. Thanks Dennis! --- John C. Bland II http://www.johncblandii.com http://www.johnandseason.com http://www.twitter.com/johncblandii --- Suggested sites: http://www.lifthimhigh.com - "Christian Products for Those Bold Enough to Wear Them" http://www.sportsmatchmaker.com - "What are you doing today?"
On Fri, Oct 9, 2009 at 2:58 PM, Dennis Clark <[email protected]> wrote: > > On Thu, Oct 8, 2009 at 8:18 PM, Sean Corfield <[email protected]>wrote: > >> >> On Tue, Oct 6, 2009 at 3:28 PM, John C. Bland II <[email protected]> >> wrote: >> > 1) Using MG, ColdSpring, and Transfer >> > There are two or three places where a datasource is set. This is >> > pretty counter-intuitive (change N places to tweak the datasource >> > name). Did I do something incorrect or is this simply going to happen? >> >> I'd expect to only put it in the Transfer config and then expose it >> via factory-bean definitions in ColdSpring should it be needed >> elsewhere in the application (do you need the datasource name anywhere >> really?). >> > > Sometimes I want to perform SQL beyond the capabilities of the ORMAdapter's > list() method and Transfer Query Language (TQL); in such cases I go back to > using the cfquery tag (or maybe cfstoredproc). Of course, I encapsulate the > code in singletons under ColdSpring, but I need to somehow pass the > datasource information to their corresponding bean definitions. > > Some of the Model-Glue sample code that's available requires the datasource > information to be provided separately from the ORM information for such > beans. The most notable case is the usermanagement actionpack bundled with > Model-Glue 3. I consider such forced duplication to be poor practice. > Fortunately the actionpack abstracts out the datasource information to its > own bean, and herein lies our solution: an adapter CFC that implements the > abstracted datasource interface for our ORM service. The following is a > datasource adapter I wrote for Transfer: > > <cfcomponent output="false" hint="I am a Datasource CFC adapter for a > Transfer ORM Factory."> <cffunction name="Init" access="public" > output="false" hint="Constructor"> > <cfargument name="transferFactory" type="any" required="true" /> > <cfset variables.transferDatasource = > arguments.transferFactory.getDatasource() /> > <cfreturn this /> > </cffunction> > > <cffunction name="GetDSN" access="public" return="string" output="false" > hint="Get property: DSN"> > <cfreturn variables.transferDatasource.getName() /> > </cffunction> > <cffunction name="GetUsername" access="public" return="string" > output="false" hint="Get property: Username"> > <cfreturn variables.transferDatasource.getUserName() /> > </cffunction> > <cffunction name="GetPassword" access="public" return="string" > output="false" hint="Get property: Password"> > <cfreturn variables.transferDatasource.getPassword() /> > </cffunction> > > </cfcomponent> > > > Writing an equivalent datasource adapter for Reactor should be just as > simple. > > Here is the ColdSpring XML for feeding the datasource information from a > Transfer ORM service to a queryGateway bean: > > <bean id="queryGateway" class="myproject.model.data.QueryGateway"> > <constructor-arg > name="datasource"><ref bean="datasource" /></constructor-arg> > </bean> > > <!-- Use an alias so we can easily switch between different datasource > adapters (or even a plain datasource CFC) --> > <alias alias="datasource" name="datasource.Transfer" /> > > <bean id="datasource.Transfer" > class="myproject.addons.transfer.DatasourceAdapter"> > <constructor-arg name="transferFactory"><ref bean="ormService.Transfer" > /></constructor-arg> > </bean> > > > With this approach, not only do we avoid duplication of the datasource > information, but our queryGateway is not tied to any specific ORM service > implementation. > > I find this pattern to be quite useful, and would like to see it (or > something like it) bundled with Model-Glue at some point in the future. > > >> >> > 2) Transfer vs Reactor >> > I know...this is a subjective question but I noticed the docs made >> > mention to Reactor for scaffolding. More-so curious as it applies to >> > MG here and not so interested in a "mine is bigger" convo. >> >> MG is ORM agnostic so you can pick whichever you want and it will "just >> work". >> > > A semantic nitpick: MG's ORM functionality is implementation-independent, > not agnostic. Implementation-independent means that MG depends only on an > abstract ORM interface, so the chosen ORM implementation can be replaced > with a different implementation without affecting your MG code. > Implementation-independent is the formal term for "pick whichever you want > and it will just work". > > Agnostic means that there is no dependency at all, not even to an abstract > interface. We want our ORM adapter to be framework-agnostic; this means that > we do not want the ORM adapter to make any calls to framework objects or > services. The key difference between this and implementation-independence is > that the ORM adapter should still work even when there *is* no framework > (hence the term agnostic). > > Of course, something has to perform the communication between the framework > to the ORM adapter. In Model-Glue, that is the job of the > GenericOrmController CFC provided by the framework. Any other framework > wanting to make use of a framework-agnostic ORM adapter would therefore need > to provide its own specific controller. > > Brian Kotek's presentation on framework-agnostic models explains in detail > why you should implement your model CFCs in a way that never references any > framework objects or services, and encapsulate all framework-to-model > communication in your controllers. The growth of Ajax frameworks and the > Flex and AIR platforms since he first made the presentation makes this > design principle more important than ever. > > Cheers, > > -- Dennis > > > > --~--~---------~--~----~------------~-------~--~----~ Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en -~----------~----~----~----~------~----~------~--~---
