RE: Reactor For CF Big update

Doug Hughes Fri, 17 Feb 2006 18:19:03 -0800

Jared,

Please allow me to be daft and ask what your goals are with this. Are you trying to automatically auto-save the address when the user is saved? Are you trying to generate a stub for the event handler and auto relate it back to the person somehow?

I’m going to assume that you want to auto-save the address. In that case, what about hasMany relationships? How would this work in that case? In particular, how about linked hasManys?

I suppose I’m asking you to talk to me like I’m an idiot. What are you doing? How would it work? How would the pattern apply across all the types of relationships?

Doug

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer
Sent: Friday, February 17, 2006 7:44 PM
To: [email protected]
Subject: Re: Reactor For CF Big update

Doug,

Is this a valid idea?

</hasOne>

</object>

It could event allow for a default stub that takes an event as an arg, calls save, sets the ID back to the wrapping record.

I don't know if this is in the plans or not, but if it is, I'd be willing to help make it so. :)

Thanks

------------------------------------------------

Jared C. Rypka-Hauer

Continuum Media Group LLC

http://www.web-relevant.com

Member, Team Macromedia - ColdFusion

"That which does not kill me makes me stranger." - Yonah Schmeidler

On Feb 17, 2006, at 3:05 PM, Doug Hughes wrote:

Hey all,

This email is being sent to let you know that I’ve committed a significant new update to Reactor. This addresses a number of issues I’ve seen with reactor and should help improve things. However, if you use many to many relationships (and who doesn’t?) you’re going to need to do more than just get the latest reactor.

Here’s what’s new:

When you have a manyToMany relationship in your app reactor no longer generates the createXyzQuery(), getXyzQuery(), and getXyzArray() methods. Instead, it generates one method, getZyzIterator(). This returns an Iterator object that encapsulates a Query object. The Iterator has a few important methods. First off, getQuery() and getArray(). These are the same as getXyzQuery(), and getXyzArray() previously. However, there are also methods that provide access to the OO query behind the scenes. You can call getwhere() to add filters directly to the Iterator, getOrder() to set the sorting of the data (in both the query and arrays you can get from this). Lastly there’s hasMore() and next() which can be used to loop over elements in the Iterator (hence the name).

Also, when you call getXyzRecord or Iterator the Record will cache the results into an instance variable. This might lead to concurrency issues if you store your record in a persistence scope (and other situations). However, it really made the most sense, in my opinion.

The Docs and samples have been updated to reflect these two changes. However, there’s another big change that’s not been documented, an event model.

Let’s say that you have a UserRecord and it hasOne AddressRecord via an addressId column. Traditionally, if you wanted to create a new User and save it you’d have to:

1) Create a userRecord

2) Populate the userRecord

3) Get/Create the addressRecord

4) Populate the addressRecord

5) Save the addressRecord

6) Set the addressRecord into the userRecord

7) Save the userRecord

Now, this is already a pain, but what if you wanted to validate the user and address before saving it? Well, that’s more complicated. However, you can now use the event model to simplify this a bit. There are eight events by default on every record: beforeValidate, afterValidate, beforeSave, afterSave, beforeLoad, afterLoad, beforeDelete, afterDelete. You can tell a record to notify another record in the case that a particular event occurs.

To start out simple, let’s say we wanted to validate the address at the same time we validate the user. Well, to do this you’d need to add a custom method to your Address record that accepts a Reactor.event.event object as an argument. You can call it whatever you want, but let’s use handleValidate() as an example. You can have the address listen for the afterValidate event like this:

Now, when you call userRecord.validate() the handleValidate() method on the addressRecord will be executed and will receive an event object. The event object contains the name of the event, the source of the event (incase you’re listening on more than one record), and optional metadata. In the case of the afterValidate event, the validaionErrorCollection object is passed along. You can get it using some code in your handleEvent method like this:

This is actually rather similar to what Joe does with events in model-glue.

You could then call the address object’s validate method and pass in that error collection. If errors are added they’ll all end up in the collection returned by the user’s validate method.

So, that’s nice. But what if you wanted to save the address before the user is saved and what if you wanted to set the user’s addressId automatically? Well, you could add a method to listen for the beforeSave event on the user. Because this contains the source of the event, you could save the address and then call the soruce’s setAddressId() method.

Here’s an example of such a method:

</cffunction>

Here’s what you’d use to make this method listen for the event:

There’s a lot more to this, but I’m going to get into it. Check out the abstractRecord and the reactor.event.event object and you’ll see where I’m headed. As time permits I’ll actually document it.

Lastly, there’s a new zip on doughughes.net which is the same as the current revision in subversion.

Doug

-- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/

RE: Reactor For CF Big update

Reply via email to