Comments on: A Couple ColdSpring AOP Gotchas

By: barneyb

barneyb — Mon, 26 Jan 2009 04:17:32 +0000

I'm not sure this is still an issue with the head releases. I rarely use dynamic defaults, but even so, I don't recall running into this issue at any point in the recent past, which makes me think it might be addressed (possibly by attributeCollection?). But to answer your question, no, I haven't dug into it at all.

By: Tony Nelson

Tony Nelson — Mon, 26 Jan 2009 02:23:44 +0000

Aside from bringing this post back from the dead, have you found a way to use dynamic default variables in ColdSpring proxied methods? I've been toying with the idea of parsing the CFC or somehow using the property's metadata to determine the literal string ("#now()#") that could then be written into the ColdSpring generated functions, but haven't had much success yet. Just curious if you explored the idea or not.

By: Sean Corfield

Sean Corfield — Sat, 21 Oct 2006 19:22:02 +0000

Heh, you're right… I'm wrong… I could have sworn that used to be the case… maybe back in CFMX 6.1? But you're right that it only evaluates the default now if the argument is *not* passed in.

By: Barney

Barney — Sat, 21 Oct 2006 14:57:17 +0000

Sean,

That's not behaviour I've witnessed, though I haven't checked in a while. What I discovered when I did test was that CFPARAM always evaluates the default attribute, but CFARGUMENT only evaluates it if it is needed. I think I actually blogged about that at some point, now that I think about it. So using a runtime default for CFARGUMENT is safe, but a runtime default for CFPARAM is not safe.

By: Barney

Barney — Sat, 21 Oct 2006 14:55:15 +0000

Steve, The aspect is basically just a CFTRANSACTION tag, so it'll work with anything you can use CFTRANSACTION with. The only caveat (at the moment) is that you can only specify a single isolation level for your entire application. I've considered addressing that via CFFUNCTION metadata, but there's no assurance that the right method's metadata will be used, as nested/reentrant transactional method invocations don't start new transactions, and therefore don't dictate the isolation level. So the isolation level is alway specified by the first transactional method encountered.

By: Sean Corfield

Sean Corfield — Sat, 21 Oct 2006 04:17:24 +0000

One caveat for defaults with dynamic values – are you aware that the default is *always* calculated even if the argument is passed? Using structKeyExists() inside the method is better practice, IMO.

By: Chris Scott

Chris Scott — Fri, 20 Oct 2006 22:59:17 +0000

Hey Barney. The first issue with default values, yep, I have been running into the same issue with cfproperty tags for as conversion. Flaky at best. But I think I can definitely put some thought into this package issue. There's got to be something I can do to work through that one. Well there kind of is, but it could have negative repercussions… Glad to hear that you are using CS's aop with success for transaction management. That's just a great use case there and many people love using Spring's aop based transaction management in java.

By: Steve Bryant

Steve Bryant — Fri, 20 Oct 2006 20:47:32 +0000

Barney,

Is your transaction management specific to one database or can it be used on any database that supports transactions?