I actually got this to work, so that the remote proxy can now have extra arguments and different arg types and return type than the original CFC. It will also let you add in default, required, etc. Additionally, you can add custom metadata like "logVars" to the method (or the parameters if you want) that will be passed in to any Advices for their use. Which means the scenario where Chris was adding custom attributes to his core object's cffunction tag to specify what his Advice would log can now be done in the XML instead.
Unfortunately there was no possible way to do all of this without modifying several of the existing ColdSpring files. On the plus side, the changes aren't very extensive, it's about 10 files and most of the changes are just a line or a couple of lines of code. I've sent the patch over to Chris to check out. On 7/12/07, Sean Corfield <[EMAIL PROTECTED]> wrote:
On 7/11/07, Chris Scott <[EMAIL PROTECTED]> wrote: > Hmm, I like the idea, but am not 100% sure this is a good thing to add to the RemoteFactoryBean. It is a big departure from what Spring offers on one hand, but more importantly, the code example looks to me like fully metaprogramming your cfcs in xml. I completely agree but it also speaks (loudly) to my complaint about why I don't use ColdSpring's Remote Proxy stuff - my remote facades often have APIs that are nothing like the original bean's API. Barney's comment about subclassing the factory is interesting tho'... If there was a nice, easy way to override how the proxy method generation was done, that would be a good start, especially if there was a nice way to special case certain methods (which is essentially what Brian tried to do). Definitely interested in seeing where this goes but I lean toward extension points in ColdSpring rather than modifying the grammar. -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood
