Is there an easy way to do remote proxies with Wirebox as a standalone? I’m used to Coldspring that makes this very easy, just mapping the CFC you want to expose remotely and list the methods to include. It looks like there’s something similar but requires Coldbox. Anything for just straight wirebox use?
Mary Jo
Hi MaryJo,
I was never a big fan of remote proxies as I thought it was the job of the MVC framework to do this and not the DI framework. However, at this point we have no plans to add remote proxies to the core, but you can easily do this via WireBox listeners. If you do create it we would love you have it contributed to ForgeBox.
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Oh that’s disappointing. Exposing specific methods in a service remotely was something I loved to use Coldspring for, rather than writing CFCs specifically to do this, and particularly something I was looking to do with the legacy app I’m working with improving. It was recommended that I switch to Wirebox as a more actively developed framework but I definitely am not looking to have to build this from scratch myself so sounds like it might not be the best choice for me after all.
Mary Jo
Sorry Mary Jo,
We do have professional services, so we could build this for you if needed. But like I said, we do not have remote proxies in the roadmap at this point in time.
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
No problem, I understand, particularly if a good solution is already built into the Coldbox platform and this is just an issue for standalone. I looked at the Coldspring code for doing this but it has a lot of parts involved so definitely not a quickie thing for me and I have too much else on my plate right now. Eventually I hope to redo this app to use a full fledged framework so I’ll certainly consider Coldbox then and will be an easy task to switch to Wirebox at that point as well. I have a lot of experience with Coldspring so wasn’t sure I wanted to take the time to learn something brand new right now as I’m really on a tight schedule with my client, and while they have a pretty strong budget, it would not be reasonable to charge them when there’s a very viable option out there. I’m going to be at cf.objective this year (as a presenter, woohoo!) so already planning to add the extra day to get some more insight into the Coldbox platform and using it when it works better for my schedule.
Mary Jo
No problem Mary Jo!
Please don’t get me wrong, if enough interest exists for remote proxies, we will build it. So why not create a ticket anyways here please:
https://ortussolutions.atlassian.net/browse/WIREBOX
Maybe somebody on the group can help out as well to port it or have some solutions they can share.
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Hi Mary Jo, just so I can understand what it is you are trying to achieve, could you explain what this remote proxy actually is used for? If I understand right, you are using ColdSpring to actually create a dynamic proxy, is that right?
Andrew Scott wrote:
Hi Mary Jo, just so I can understand what it is you are trying to
achieve, could you explain what this remote proxy actually is used
for? If I understand right, you are using ColdSpring to actually
create a dynamic proxy, is that right?
Yes exactly, a dynamic proxy. So let’s say I have a large CFC service with lots of methods, and I need to expose a selection of them remotely for my Ajax calls. I can just define a remoteservice to that CFC and list the methods to have remote access and Coldspring will wire that up for me, rather than my having to add another CFC or expose them remotely in my service layer. It’s pretty handy and makes it really easy as well to see what methods you currently are using remotely.
Mary Jo
Andrew Scott wrote:
Hi Mary Jo, just so I can understand what it is you are trying to
achieve, could you explain what this remote proxy actually is used
for? If I understand right, you are using ColdSpring to actually
create a dynamic proxy, is that right?
Coldspring doc for doing them:
http://www.coldspringframework.org/coldspring/examples/quickstart/index.cfm?page=remote
Mary Jo
If I understand the ColdSpring documentation, it is technically not dynamic because the rules have to be defined by the ColdSpring rules at run time. I think in that case, you have a couple of options, switching over and using ColdBox where this would be made a lot easier and less configuration with ColdBox and using Restful calls.
Or as Luis mentioned, you might need to look into the listeners and AOP side of this and create an Aspect that could define this rule or a set of rule definitions to then provide what you are looking for. Personally, I don’t see any benefits to exposing an API dynamically for remote access like this.
Andrew Scott wrote:
If I understand the ColdSpring documentation, it is technically not dynamic because the rules have to be defined by the ColdSpring rules at run time.
Ah no not dynamic in that respect, but just in terms of it being created on the fly rather than a CFC we have to maintain.
I think in that case, you have a couple of options, switching over and using ColdBox where this would be made a lot easier and less configuration with ColdBox and using Restful calls.
Not in my budget or given timeframe. I'm working with a legacy app that is using its own sort of pseudo MVC so will have to clean it up a bit at a time.
Or as Luis mentioned, you might need to look into the listeners and AOP side of this and create an Aspect that could define this rule or a set of rule definitions to then provide what you are looking for. Personally, I don't see any benefits to exposing an API dynamically for remote access like this.
Not really sure how I'd do this with listeners off hand but this isn't really stuff I know the ins and outs of that well. As for the benefit, less code to maintain, and keeping the remote calls separate from the main service layer. No, there's no real "benefit" unless you consider easier code maintainability a benefit, or don't care if your remote stuff is mixed in with everything else.
MJS
Yes the pain of legacy apps!
Hi Mary, Luis and I will both be at cf.Obejctive() and I don’t think we’ve met so I’ll be looking forwarding to talking to you there. Please look at coming in a day early to catch our Into The Box conference http://www.intothebox.org/ We’ll be having sessions on all the Box products and legacy conversions is one of our focuses this year.
Now, on to your question-- I think I’m with Luis in that it doesn’t seem like the job of a DI engine to be exposing remote proxies-- that should be up to the MVC framework. The remote proxy feature of ColdSpring is interesting though I can’t say I’ve ever heard about it, nor has anyone asked for it before.
After reading about it, I’m not sure if I see the benifit, but again I’m a little turned off by gratuitous XML and I prefer to build my applications with CFML, not configuration. They have an example that takes 25 lines of XML, but I can accomplish the same thing with WireBox using old fashioned CFML in 14 lines of code (including whitespace). What’s more, this remote proxy is also using dependency injection AND AOP. (In my test, I used the “secure” annotation to automatically bind an aspect) Did I mention there was no XML for any of that? 
I also prefer the code approach since I often times need to massage, default, or validate incoming parameters from the remote call before calling the service. Likewise, sometimes I like to present the output of the service differently.
Of course, if you’re using ColdBox, remote proxies can also execute regular ColdBox events as well.
RemoteLanguageService.cfc
component {
property name=‘languageService’ inject=‘languageService’;
application.wirebox.autowire( target=this );
remote function reverseString() secure {
return languageService.reverseString( argumentCollection = arguments );
}
remote function duplicateString() secure {
return languageService.duplicateString( argumentCollection = arguments );
}
}
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
wrote: Hi Brad…actually I go by Mary Jo or just MJ. Both words comprise my first name (nothing worse than having an unusual name, believe me!) I’m already signed up. 
I don’t necessarily disagree, but it’s a neat feature that I’ve often used before and had planned to for this project. Keep in mind not everyone is working with a full-fledged MVC framework if they are using wirebox as a standalone. Guess it may be what you are used to as well. I actually always kind of liked having the CS config file to almost be a complete document of all the beans and properties, etc. in the application. The Coldspring remote proxy example may be 25 lines of XML but keep in mind you never need more than that no matter how many remote methods you are creating while the resulting component it generates could have many more lines when completed. The latest 2.0 version creates a really nice lightweight proxy that is a big improvement on the previous version. Still, I’m leaning towards using wirebox regardless. As you say, it’s not uncommon to need to do more with remote objects, and I’m thinking I might switch to using a common response object which would require creating them from a parent class. Mary Jo