Hi, thanks for the great tutorials. I am new to all this so I might be asking a silly question, but I was wondering why are you using functions that operate solely on their arguments and don't return any values? For example:
<cffunction name="loadContact" access="public" returntype="void" output="false">
<cfargument name="contact" type="any" required="true"/>
<cfset getContactDAO().read( arguments.contact ) />
</cffunction>
Does it offer some advantage over a code simply returning object both from the contactDAO.read() and contactService.loadContact() method?
For example if I implemented some views in Flex, methods in the service component returning values could be easily consumed remotely:
<cffunction name="loadContact" access="remote" returntype="any" output="false">
<cfargument name="contact" type="any" required="true"/>
<cfreturn getContactDAO().read( arguments.contact ) />
</cffunction>
Just I'm thinking about integrating MG with Flex and it looks that the service component could also serve remote requests. Or am I missing the point here?

strix,

You are on the right track. The ContactOMatic is an academically simple application with emphasis on using ModelGlue and ColdSpring effectively.

If I was building the model/service layer for a real world application, there are a number of things I might do differently. For example, if I was going to expose part of my model remotely, I would probably not use the UserService as you see it in code. I would have a proper remote service. (Check into the ColdSpring remote service factory. )

Of course, a remote service can call other services/model objects as is appropriate for the transaction. The methods in those objects could operate on the reference, or return it, as long as the value was in scope for the remote function to serialize the data and return it over the wire.

Thanks for bringing this point up. I bet it will help someone else.

DW

About to finish in the series and learning a lot along the way.

I have a question.
On the function "getContactForm" presented on this page I can see that we are loading values from the DB using this line <cfset ContactService.loadContact( ContactFormBean ) /> right after that we are making a call to event.makeEventBean(ContactFormBean). From what I understand the makeEventBean() will grab variables from the "event" and run the setters for those variables in the ContactFormBean. I see it as a quick way to "load" what's on the FORM scope (through the MG event) and fill up the bean.
So if my assumptions are correct and that's what makeEventBean actually does, then why are we calling it right after loading data from the DB?

I would think that the function would work the same if we made some changes
---Original----
<cffunction name="getContactForm" access="public" returnType="void" output="false">
<cfargument name="event" type="any">
<cfset var ContactFormBean = getModelGlue().getBean("ContactFormBean") />
<cfset var ContactService = getModelGlue().getBean( "ContactService") />
<cfset ContactFormBean.setContactID( arguments.event.getValue("ContactID") ) />
<cfset ContactService.loadContact( ContactFormBean ) />
<cfset arguments.event.makeEventBean( ContactFormBean ) />
<cfset arguments.event.setValue( "ContactFormBean", ContactFormBean ) />
</cffunction>

-----New-----
<cffunction name="getContactForm" access="public" returnType="void" output="false">
<cfargument name="event" type="any">
<cfset var ContactFormBean = getModelGlue().getBean("ContactFormBean") />
<cfset var ContactService = getModelGlue().getBean( "ContactService") />
<cfset arguments.event.makeEventBean( ContactFormBean ) />
<cfset ContactService.loadContact( ContactFormBean ) />
<cfset arguments.event.setValue( "ContactFormBean", ContactFormBean ) />
</cffunction>

Basically getting rid of the line that gets the ContactID value from the event and replace it with the arguments.event.makeEventBean. This will happen before the ContactService.loadContact() call and will effectively load the ContactID in the contactFormBean.

Are these assumptions correct?

Fernando

Hi Fernando,

Thanks for dropping in again. I see where you are going with this and you are keen to ask the question. However, there is a difference between the Original and the New version in your comment.

The purpose of the Original code is to load the object from the database, then add in any passed form variables. So if I have an existing contact, and I wish to edit one of the fields, what would happen is, the contactbean.contactID is set, then the object is loaded from the database. THEN any matching form elements are set into the object. At this point, the contactbean now matches the form.

However, in your 'new' example, something is lost.
In your code, you get a contactbean, load the form variables, THEN load the record from the database. As you can probably see, any changes to the object that come from the form, are overwritten when the object is loaded from the database. So if this process happens after the user tried to change the name of a contact, that new name will be overwritten when you load the object from the DB.

Do you see the subtle, but important difference?

DW

Something else I found.

On the post you mention "ContactService.deleteContact()" but in the code the ContactService has a removeContact(). Nothing major but something that may confuse people.

AHA!! subtle but very important distinction. It seemed OK to me but I realized my mistake after reading what you said. It all became very clear when I changed my validation rules a bit and had to return to the same form. Since on my "new" code the last step was to load from the DB I was effectively clearing any values entered on the form and returning to the form showing nothing.

I changed things the way they were and now after a 'failure' on the validation I can see the original values.

Thanks much for taking the time Dan. Learning a lot from this series.