Sweet! Thanks for the link.
I'm totally interested in 'lab' type stuff for CFUG meetings. I seem to
be able to get my head around new concepts better when I can put my
hands on them. Add to that someone walking through processes while I
follow along, and it's just that much better. I'm a self taught guy,
and ColdFusion and _javascript_ have been all that's introduced me to OO.
The next thing I was going to do was look up some information on the
facade pattern. You're the second person I've heard use the term (Rob
Gonda being the other one), and so I figure that I ought to learn a bit
about it.
I'm working on a project for a client that is replacing an old DOS
based app with our new CF app., and it just gets more and more complex
as time goes on. So, I'm always looking for ways that can make my life
easier.
Okay, I'm done blabbering. Just a quick trip home, and I'll kick back
to read the link you gave.
Thanks!
Chris :)
Dave Shuck wrote:
Chris,
It is partly technique for sure, such as using the facade pattern and
choosing to store data in memory as opposed to continual database
interaction, but using the Reactor ORM framework makes these techniques
very simple, and manages all of the relationship part of it, such as
the child iterator objects for hasMany type relationships.
You can find more on Reactor here:
http://trac.reactorframework.org
Using Reactor, you can specify all your object relationships via XML.
That is what allows for such ease of the parent/child relationships.
But there are countless other things that it gives you, such as
database abstraction ability through introspection of the database, the
ability to use aliases for badly named databases, and much much more.
Aaron and I have talked about putting together a Reactor presentation
for the CFUG. Maybe we could even do some type of lab where we walk
through building a sample application if there is any interest in
something like that over a presentation.
~Dave
On 8/10/06, Christopher Jordan <[EMAIL PROTECTED]> wrote:
Dave this
looks really cool, but can you tell me
exactly which part of it is Reactor? I've not heard of Reactor before.
Is it more of a technique or what?
Thanks
Chris
Dave Shuck wrote:
Anyone that has
talked to me in the last half year knows
that I am kind of enamoured with Reactor. In my evangelism efforts for
a product that I really love, I thought I would post it here on the
list for those that don't keep up with the blogging world.
The original post can be found at:
http://www.daveshuck.com/index.cfm?commentID=152
___________________
Don't think that
Reactor is just for database abstraction!
Even if database abstraction was all that Reactor did, I would still
use it because it does it very well. However, the more I use it the
more I realize that that is actually just a small part of what I love
about it.
Take for example the current application that I am working on. It is a
mortgage loan application where a User can have multiple
LoanApplications. A LoanApplication can have multiple Borrowers.
Borrowers can have multiple Properties. Properties can have multiple
Liabilities.
While it is certainly possible to hand code these relationships in your
CFCs, it is a *LOT* of work. In our new efforts, we are taking the
following approach and finding that it is a sweet way to go.
To explain a bit, we are refactoring an application that does about 40
bazillion queries on every request as a user steps through 9 tabbed
pages in the application. We have modified that approach quite a
bit. In our new model, the loan application itself it a single HTML
document with client-side tabbing. Before the user steps into the
application, we have loaded a very basic LoanApplication object into
our LoanApplicationFacade. So now when we need to access/modify any
data, we can access it through that single entry point.
Our active LoanApplication starts out with just some very basic details
and a single borrower. As the user walks through the application we
are using AjaxCFC to update and construct the LoanApplication object
behind the scenes. This is where Reactor really begins to come into
play.
For instance, say we add a co-borrower. This is as simple as this:
CoBorrower =
LoanApplicationFacade.getLoanApplication().getBorrowerIterator().add();
Just by doing this, we now have a second borrower that is part of the
loan application. When we add an asset property to this CoBorrower, we
can do this:
NewProperty
= CoBorrower.getPropertyIterator().add();
... and so on. Using these relationships, managing the entire
LoanApplication object is a breeze.
So, say for some reason I want to create a list of all cities that the
Borrowers own property in. I can do something like this:
<cfset
CityList = "" />
<cfset
BorrowerIterator = LoanApplicationFacade.getLoanApplication()
/>
<cfloop
condition=#BorrowerIterator.hasMore()#>
<cfset ThisBorrower = BorrowerIterator.getNext() />
<!--- now loop through this Borrower's Properties --->
<cfset PropertyIterator = ThisBorrower.getPropertyIterator() />
<cfloop condition=#PropertyIterator.hasMore()#>
<cfset ThisProperty = PropertyIterator.getNext() />
<cfset ListAppend(CityList,ThisProperty.getCity()) />
</cfloop>
</cfloop>
The
cities are: <cfoutput>#CityList#</cfoutput>
So back to our application, we have decided that databases are
overrated! Rather than continually making these unnecessary round
trips, we are just building this object into memory. We are only
actually persisting it under two scenarios, those being if the user
actually submits their loan application, or OnSessionEnd(). Now, that
we are actually to the point of database interaction, I can point out
another really cool piece of Reactor. Rather than looping through all
of these objects by hand, saving them, then saving the relationships,
etc., the beauty of cascading saves comes to the rescue! For
example, in our Application.cfc OnSessionEnd(), we have the following
code:
try {
if (LoanApplication.loanApplicationExists()) {
LoanApplicationFacade.getLoanApplication
().save();
SessionSaved = true;
}
}
catch(Any
excpt) {/* an error occurred while saving */}
Now obviously it is a HUGE thing that we only have to call a single
save() to save everything about our LoanApplication, but to me this
still isn't the big deal. The truly big deal to me is the ease at
which I can manage these relationships. In fact, with the way these
relationships are structured, writing save routines by hand would be a
breeze as you can see in the Reactor core files.
--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com
www.worldwildweb.biz
_______________________________________________
Reply to DFWCFUG:
[email protected]
Subscribe/Unsubscribe:
http://lists1.safesecureweb.com/mailman/listinfo/list
List Archives:
http://www.mail-archive.com/list%40list.dfwcfug.org/
http://www.mail-archive.com/list%40dfwcfug.org/
DFWCFUG Sponsors:
www.HostMySite.com
www.teksystems.com/
--
~Dave Shuck
[EMAIL PROTECTED]
www.daveshuck.com
www.worldwildweb.biz
_______________________________________________
Reply to DFWCFUG:
[email protected]
Subscribe/Unsubscribe:
http://lists1.safesecureweb.com/mailman/listinfo/list
List Archives:
http://www.mail-archive.com/list%40list.dfwcfug.org/
http://www.mail-archive.com/list%40dfwcfug.org/
DFWCFUG Sponsors:
www.HostMySite.com
www.teksystems.com/
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.8/415 - Release Date: 8/9/2006
|
