Re: fix for moving legacy code to application.cfc w/ local variab les
It would be nice if, in the future, FR/WS calls simply didn't try to run onRequest. On 6/3/05, Sean Corfield <[EMAIL PROTECTED]> wrote: > On 6/3/05, Calvin Ward <[EMAIL PROTECTED]> wrote: > Note that the primary reason for using onRequest() is to set variables > scope data that is accessible in your .cfm page - this scenario simply > doesn't apply for web service / Flash Remoting calls! > -- > Sean A Corfield -- http://corfield.org/ > Team Fusebox -- http://fusebox.org/ > Got Gmail? -- I have 50, yes 50, invites to give away! > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208528 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: fix for moving legacy code to application.cfc w/ local variab les
That certainly makes sense. I recall seeing something about needing to use onRequest to leverage onError in a certain fashion, but I'll be darned if I can remember where I saw that... - Calvin On 6/3/05 10:20 AM, "Sean Corfield" <[EMAIL PROTECTED]> wrote: > On 6/3/05, Calvin Ward <[EMAIL PROTECTED]> wrote: >> How would you recommend working around the remoting/gateway issue? Simply by >> not using OnRequest (which impacts the ability to use OnError), or would you >> have a different solution? > > I would use a different Application.cfc and have the web services / > remoting CFCs in their own directory. For commonality, both this > Application.cfc and your primary own could extend the same code CFC > (containing the common Application.cfc methods). Your primary > (webroot) Application.cfc would then add onRequest(). > > Another option is to have Application.cfc's onRequestStart() method > check if targetPage ends in ".cfc" and, if so, do > structDelete(variables,"onRequest"); structDelete(this,"onRequest"); > (you need both). > > Note that the primary reason for using onRequest() is to set variables > scope data that is accessible in your .cfm page - this scenario simply > doesn't apply for web service / Flash Remoting calls! ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208516 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: fix for moving legacy code to application.cfc w/ local variab les
On 6/3/05, Calvin Ward <[EMAIL PROTECTED]> wrote: > How would you recommend working around the remoting/gateway issue? Simply by > not using OnRequest (which impacts the ability to use OnError), or would you > have a different solution? I would use a different Application.cfc and have the web services / remoting CFCs in their own directory. For commonality, both this Application.cfc and your primary own could extend the same code CFC (containing the common Application.cfc methods). Your primary (webroot) Application.cfc would then add onRequest(). Another option is to have Application.cfc's onRequestStart() method check if targetPage ends in ".cfc" and, if so, do structDelete(variables,"onRequest"); structDelete(this,"onRequest"); (you need both). Note that the primary reason for using onRequest() is to set variables scope data that is accessible in your .cfm page - this scenario simply doesn't apply for web service / Flash Remoting calls! -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208504 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: fix for moving legacy code to application.cfc w/ local variab les
> > First, what's wrong with setting local variables in Application.cfm? > > I don't like the (potential) scoping implications of it... > local variables set in the application.cfm, particularly for > some of the most common variables that are set this way > (dsn/datasource for instance) are then not available to > custom tags. Sure you can add variables.dsn> on the line below, but then you're doubling up > the code needed to set it, and in the individual pages you've > got some references to request.dsn and lots of references to > #dsn# (with no scope). It boils down more to a matter of bad > scoping habbits than one really of setting variables in the > application.cfm, but personally I consider it poor practice > to set local variables there -- much better to use > Application.cfm only to set request, cookie and > persistent-scope variables. It is a mistake to extrapolate from the fact that you don't like something, that it is a bad practice. There's nothing wrong with setting local variables within Application.cfm. If you do so, they won't be available to custom tags; you are certainly right about that. But in most cases, there's no need to make them available to custom tags, if those custom tags are written so as to be as loosely coupled to the application as possible. If you explicitly want to use the Request scope, you can use that instead, but that doesn't make the use of the local Variables scope within Application.cfm a bad practice. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208499 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: fix for moving legacy code to application.cfc w/ local variab les
>First, what's wrong with setting local variables in Application.cfm? I don't like the (potential) scoping implications of it... local variables set in the application.cfm, particularly for some of the most common variables that are set this way (dsn/datasource for instance) are then not available to custom tags. Sure you can add on the line below, but then you're doubling up the code needed to set it, and in the individual pages you've got some references to request.dsn and lots of references to #dsn# (with no scope). It boils down more to a matter of bad scoping habbits than one really of setting variables in the application.cfm, but personally I consider it poor practice to set local variables there -- much better to use Application.cfm only to set request, cookie and persistent-scope variables. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208496 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: fix for moving legacy code to application.cfc w/ local variab les
Sean, How would you recommend working around the remoting/gateway issue? Simply by not using OnRequest (which impacts the ability to use OnError), or would you have a different solution? - Calvin -Original Message- From: Sean Corfield [mailto:[EMAIL PROTECTED] Sent: Friday, June 03, 2005 12:10 AM To: CF-Talk Subject: Re: fix for moving legacy code to application.cfc w/ local variab les On 6/2/05, Dave Watts <[EMAIL PROTECTED]> wrote: > No, don't use OnRequest - that will replace the page that was actually > requested. You could use OnRequestStart, or just put them in the > "pseudo-constructor" area I think. No, if you want page-local variables to be accessible in the requested page, you *must* use onRequest(). If you do not use onRequest(), variables set in onRequestStart() are accessible in onRequestEnd() but not in the main page you requested. As soon as you use onRequest(), all three methods share the same variables scope and onRequest() s the requested page. However, you cannot use onRequest() in an Application.cfc that controls CFCs that are accessed as Web Services, via Flash Remoting or as Event Gateways. Read the documentation for more details on that. -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208483 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
Re: fix for moving legacy code to application.cfc w/ local variab les
On 6/2/05, Dave Watts <[EMAIL PROTECTED]> wrote: > No, don't use OnRequest - that will replace the page that was actually > requested. You could use OnRequestStart, or just put them in the > "pseudo-constructor" area I think. No, if you want page-local variables to be accessible in the requested page, you *must* use onRequest(). If you do not use onRequest(), variables set in onRequestStart() are accessible in onRequestEnd() but not in the main page you requested. As soon as you use onRequest(), all three methods share the same variables scope and onRequest() s the requested page. However, you cannot use onRequest() in an Application.cfc that controls CFCs that are accessed as Web Services, via Flash Remoting or as Event Gateways. Read the documentation for more details on that. -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208481 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: fix for moving legacy code to application.cfc w/ local variab les
> I think you can use the OnRequest method (be sure to read up > on it) and anything declared there will be fine as local > variables just like Application.cfm. No, don't use OnRequest - that will replace the page that was actually requested. You could use OnRequestStart, or just put them in the "pseudo-constructor" area I think. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208425 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
RE: fix for moving legacy code to application.cfc w/ local variab les
> I'm betting the answer to this is no, but has anyone found a way of > migrating an existing application.cfm to the onRequestStart portion of > an Application.cfc while maintaining the viability of local variables > that had been set in the Application.cfm? I know it's a bad practice > -- wasn't my idea. :) I was just kinda hoping (likely futile) that > there might be a workaround to allow us to use application.cfc in > spite of the bad practice. First, what's wrong with setting local variables in Application.cfm? Second, you can just set them in Application.cfc the same way. Just don't put them in a function, and they'll work just like in Application.cfm. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:208423 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
