Brian Kotek wrote, On 6/8/2007 2:18 PM:
Philip, questions are good. However, these questions don't really have
any bearing on why you would use ColdSpring. It makes no difference
what my database tables look like, what methods the CFCs have, what
the datasource looks like, what mapping you use for your component
paths, or what the index.cfm or maintenance screens look like.
But, it would be good to know/understand why you have so many classes
(for what seems like it should just be a simple Product class), what
they are doing, and why you have designed them that way.
It would be off topic to the expressed subject, but it would be good. =)
Sam
What ColdSpring does is create CFCs for you and manage their
relationships so you don't have to (it also does a lot more such as
AOP and remote facade generation but those are separate topics). It's
completely generic. It will work with any CFCs, whether you are using
a database or not, and regardless of what the CFCs actually do or how
you display the data they provide.
However, if code would help, have a look at the code from my
presentation at the Frameworks conference earlier this year:
http://www.briankotek.com/blog/files/framework_agnostic_models_presentation_code.zip
Hope that helps,
Brian
On 6/8/07, *Phillip Senn* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Thanks Brian for your posts.
In your blog, you use this as an example:
<beans>
<bean id="productService" class="components.ProductService">
<constructor-arg name="productFactory">
<ref bean="productFactory" />
</constructor-arg>
<constructor-arg name="productDAO">
<ref bean="productDAO" />
</constructor-arg>
<constructor-arg name="productGateway">
<ref bean="productGateway" />
</constructor-arg>
</bean>
<bean id="productDAO" class="components.ProductDAO">
<constructor-arg name="config">
<ref bean="config" />
</constructor-arg>
</bean>
<bean id="productGateway" class="components.ProductGateway">
<constructor-arg name="config">
<ref bean="config" />
</constructor-arg>
</bean>
<bean id="config" class="components.config">
<constructor-arg name="configFile">
<value>/config/configFile.xml</value>
</constructor-arg>
</bean>
<bean id="productFactory" class="components.ProductFactory" />
</beans>
1. What does the Product table look like?
2. What does ProductService.cfc look like?
3. What does ProductFactory.cfc look like?
4. What does ProductDAO.cfc look like?
5. What does ProductGateway.cfc look like?
6. What does Config.cfc look like?
7. What does Application.cfc look like?
8. What does your ColdFusion datasource look like in the cfide
administrator?
9. What does your mapping look like if you refer to
myapp.components.?
10. What does your Index.cfm page look like?
11. What does your maintenance screen look like?
12. What does your Report screen look like?
13. What does your Inquiry screen look like?
When I use the phrase "look like", what I'm trying to convey to
you is:
"What is the exact source code for this /thing/ which I'm
describing, whether it be a sql script, a ColdFusion component, a
cfm page that outputs plain old HTML with javascript and cascading
style sheets, or a cfm page that outputs a flex application".
I'm trying to show you that I'm not trying to be obnoxious, but
rather that I have lots of questions.
You are subscribed to cfcdev. To unsubscribe, please follow the
instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
