Reactor: A LOT Like a Wendys Drive Through
Okay, I've been up since 3 A.M (went to bed waaay too early last night) working on a Modelglue project, and now I'm feeling the need to rant a little bit. Not complain, per se, because I truly do appreciate the blood, sweat, and tears that must have gone into creating the frameworks that comprise Unity; But out of the 4 hours I "worked", a full third of it was spent on issues related to trying to get my app to "see" certain kinds of changes, even WITH my cheat sheet (which itself was born out of a lot of time spent pulling my hair and bumping around in the dark). That's just a wee bit much for something that's supposed to help me spend my time more efficiently, wouldn't you agree? In particular, this morning my beef is with Reactor.
Reactor has a Development mode and a Production mode. In theory, I should put this baby in Dev gear and just leave it there until I'm ready for production. But, Dev mode is just plain slow as molasses in January, so I opt rather to work with Reactor in production mode until and unless I make a change directly related to the database. This morning happened to be one where I had added some fields to a table. So I make my table changes, change Reactor to Development mode, and reinit the app. I then walk through my app as a user would to the point where I KNOW this particular table's record object is needed. It HAS to do be done this way, you know. If I didn't, Reactor would not have re-created my object for me, DESPITE the fact that I re-init'd the app, because it is a WHOLE lot like a Wendy's drive-through: neither one creates it until you actually order it. Okay, so now I am able to successfully edit and insert records containing values for these new fields, so I must have ordered my burger right (pun intended). As usual, I now switch back to production mode for efficiency's sake. More testing, and I realize that something's amiss with one of my fields...I'm getting a sql error when trying to do an update after having edited a value. BUT HEY NOW! WAIT JUST A MINUTE! HOW can I be getting a SQL error when I'm using Reactor validation to check values before attempting to insert them? This cannot be! And yet, it is. After fiddle farting around with double checking syntax, making sure quotes were correct, field names and form field names correlated...it finally occurred to me to open up the Reactor validator object for this table, JUST TO MAKE SURE it looked right. Surely it would be right. After all, I KNOW I did what Reactor required of me to regenerate that table's objects. Sure enough, though, no validators existed for the new fields. DANG IT! Apparenly Reactor only regenerated the SPECIFIC Reactor objects I needed for the functions I performed before switching back to production mode. Back to development mode, re initialize the app, walk through as a user to the point where I INVOKED VALIDATION, then all was well.
When I finally DID get everything working well and regenerated in my local environment, I then committed my changes via SVN to the repository and ran the update for our testing environment. We aren't including Reactor's base project CFCs in our repository, so now it was time to switch to dev mode in Test and regenerate. Ay, here I go again, having to login in as a user and physically "touch" the app in a lot of places to force Wendy...er, Reactor, to make my burger. You can imagine how much time it can potentially take when you have to go into the app and USE it in order to make changes happen on the backend like that. And what if you don't know the app from the front end? What if you're job only entails backend work? Then you're either forced to learn the app, or wait for your testers to go in and tell you if it worked or not. Either way, it's not efficient use of time.
My rant is just this: why's it gotta be so painful to use Reactor? Why do I NEED an initialization cheat sheet when developing with it? If I've jumped through the fiery hoop to get Reactor to regenerate my table's record object, why can't it just regenerate ALL of the objects for that particular table in one fell swoop??? WHY am I FORCED to know the app from the FRONTend in order to manifest a change on the BACKend (Reactor's whole, "I won't make it for ya till you order it!" philosophy)? What if all I was hired to do was back end coding and don't know the app well enough from the user's perspective to properly navigate my way through to where my code change lives?
Perhaps I'm just using this awesome tool the wrong way; I don't think so, though. I've worked with several other people together on MG projects, I've read just about everything out there that has to do with MG:Unity, I've got a LOT of hours logged getting my hands dirty with this framework, and I haven't seen anybody else do it any different than I. If I had a magic wand, I would wave it and miraculously "init=true" really WOULD reinitialize my app completely! As it stands now though, it's kind of a pain.
Okay, I'm done venting. Thanks for listening. ModelGlue:Unity, I still love you.
Doug out.
Reactor has a Development mode and a Production mode. In theory, I should put this baby in Dev gear and just leave it there until I'm ready for production. But, Dev mode is just plain slow as molasses in January, so I opt rather to work with Reactor in production mode until and unless I make a change directly related to the database. This morning happened to be one where I had added some fields to a table. So I make my table changes, change Reactor to Development mode, and reinit the app. I then walk through my app as a user would to the point where I KNOW this particular table's record object is needed. It HAS to do be done this way, you know. If I didn't, Reactor would not have re-created my object for me, DESPITE the fact that I re-init'd the app, because it is a WHOLE lot like a Wendy's drive-through: neither one creates it until you actually order it. Okay, so now I am able to successfully edit and insert records containing values for these new fields, so I must have ordered my burger right (pun intended). As usual, I now switch back to production mode for efficiency's sake. More testing, and I realize that something's amiss with one of my fields...I'm getting a sql error when trying to do an update after having edited a value. BUT HEY NOW! WAIT JUST A MINUTE! HOW can I be getting a SQL error when I'm using Reactor validation to check values before attempting to insert them? This cannot be! And yet, it is. After fiddle farting around with double checking syntax, making sure quotes were correct, field names and form field names correlated...it finally occurred to me to open up the Reactor validator object for this table, JUST TO MAKE SURE it looked right. Surely it would be right. After all, I KNOW I did what Reactor required of me to regenerate that table's objects. Sure enough, though, no validators existed for the new fields. DANG IT! Apparenly Reactor only regenerated the SPECIFIC Reactor objects I needed for the functions I performed before switching back to production mode. Back to development mode, re initialize the app, walk through as a user to the point where I INVOKED VALIDATION, then all was well.
When I finally DID get everything working well and regenerated in my local environment, I then committed my changes via SVN to the repository and ran the update for our testing environment. We aren't including Reactor's base project CFCs in our repository, so now it was time to switch to dev mode in Test and regenerate. Ay, here I go again, having to login in as a user and physically "touch" the app in a lot of places to force Wendy...er, Reactor, to make my burger. You can imagine how much time it can potentially take when you have to go into the app and USE it in order to make changes happen on the backend like that. And what if you don't know the app from the front end? What if you're job only entails backend work? Then you're either forced to learn the app, or wait for your testers to go in and tell you if it worked or not. Either way, it's not efficient use of time.
My rant is just this: why's it gotta be so painful to use Reactor? Why do I NEED an initialization cheat sheet when developing with it? If I've jumped through the fiery hoop to get Reactor to regenerate my table's record object, why can't it just regenerate ALL of the objects for that particular table in one fell swoop??? WHY am I FORCED to know the app from the FRONTend in order to manifest a change on the BACKend (Reactor's whole, "I won't make it for ya till you order it!" philosophy)? What if all I was hired to do was back end coding and don't know the app well enough from the user's perspective to properly navigate my way through to where my code change lives?
Perhaps I'm just using this awesome tool the wrong way; I don't think so, though. I've worked with several other people together on MG projects, I've read just about everything out there that has to do with MG:Unity, I've got a LOT of hours logged getting my hands dirty with this framework, and I haven't seen anybody else do it any different than I. If I had a magic wand, I would wave it and miraculously "init=true" really WOULD reinitialize my app completely! As it stands now though, it's kind of a pain.
Okay, I'm done venting. Thanks for listening. ModelGlue:Unity, I still love you.
Doug out.
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Re: Reactor: A LOT Like a Wendys Drive Through
Hey Doug,
The way my company handles this is we simply delete all the reactor files from the /project directory. Then, even in production mode reactor will auto-generate the files as needed. But if the files exist, then they are not recreated.
We do this with a url param called fullreinit. If it and a password are seen by the onRequestStart function in App.cfc, then happens.
Hope this helps.
The way my company handles this is we simply delete all the reactor files from the /project directory. Then, even in production mode reactor will auto-generate the files as needed. But if the files exist, then they are not recreated.
We do this with a url param called fullreinit. If it and a password are seen by the onRequestStart function in App.cfc, then happens.
Hope this helps.
Posted by Matt Williams on September 12, 2007 at 3:56 PM
Re: Reactor: A LOT Like a Wendys Drive Through
Thanks Matt, I like your input. It just seems to me, though, that the framework ought to have similar functionality built in, don't ya think? :)
Posted by dougboude on September 12, 2007 at 4:28 PM
Re: Reactor: A LOT Like a Wendys Drive Through
Doug - I appreciate the criticisms. To be totally honest they're all valid. (And don't get me started on iterators.) The one thing I do have to say is that there are some approaches that are easier than others. Like you, I keep everything in production mode and only recreate the objects when I need to. (I think I have a url variable or something I use for this purpose. It's been a while, honestly.) And yea, I know validation needs work and so forth. It's a challenge doing all of this. :) For what it's worth I've been scheming on an update/replacement for Reactor for, well, a year. All things in good time I guess.
@Matt - Reactor has a method, compile() which creates any objects. So, we never put any of the generated objects (or anything under /reactor/project) into SVN. When we publish we simply have a routine that we run that calls ReactorFactory.compile() and that generates all the /project files. Everything else should be in SVN and just work.
Anyhow, I really appreciate that you're out there and working with it, if nothing else. :)
Doug Hughes
@Matt - Reactor has a method, compile() which creates any objects. So, we never put any of the generated objects (or anything under /reactor/project) into SVN. When we publish we simply have a routine that we run that calls ReactorFactory.compile() and that generates all the /project files. Everything else should be in SVN and just work.
Anyhow, I really appreciate that you're out there and working with it, if nothing else. :)
Doug Hughes
Posted by Doug Hughes on September 12, 2007 at 8:32 PM
Re: Reactor: A LOT Like a Wendys Drive Through
Aw, Doug, I hope you took all of my ranting in a positive way deep down, too! Like I ended the post with, I still love my Unity and won't be switching frameworks anytime in the near future. I honestly don't know how you found time to get it to the point it's at...accomplishing things of that magnitude on the side...well, it says a LOT about your skills and dedication to the community. You are to be highly commended, man.
Doug Boude
Doug Boude
Posted by dougboude on September 12, 2007 at 10:58 PM