aop & internal method calls

[Chris Blackwell]

I've just stumbled into a situation where i'd like my aspects to be applied to a method called internally on a proxied cfc

I'm using an aspect  to apply security to controller methods, here's an example

function context(rc) {

  if(rc.hasID()) context_edit(rc);

  else context_list(rc);

}

function context_list(rc) authorize="context_list" {

  fw.setView(".context_list");

  rc.contexts = RouteService.listContexts();

}

function context_edit(rc) authorize="context_edit" {

  fw.setView(".context_edit");

  rc.context = RouteService.getContext(rc.id);

}

so depending on if the request is for /context or /context/:id i'm switching the controller method, but as the method call for context_list() or context_edit() are internal the aop proxy doesn't get a chance to intercept them.

given that cfml allows you to dynamically swap methods on a cfc, i'm wondering if there's any way to alter the aspect to replace the method in the target with one that sends the method call via the proxy? does that make sense, or am i talking gibberish :)

I guess i might work something like

• target method gets renamed, eg. originalMethod() --> __proxied_originalMethod()
  
• proxy injects itself into the target cfc
• proxy replaces original method with new method that calls the proxy, eg.
  function originalMethod() {
    return variables.__injectedProxy.__proxied_originalMethod();
  }

Might something like that work ?

Cheers, Chris

[Brian Kotek]

I'd just move the context() method or the two internal methods into another class that is proxied and injected into whatever needs to use it. Seems like that would be a lot easier than trying to swap the real methods with the proxied methods in the same object.

--
You received this message because you are subscribed to the Google Groups "ColdSpring-Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coldspring-use...@googlegroups.com.
To post to this group, send email to coldspri...@googlegroups.com.
Visit this group at http://groups.google.com/group/coldspring-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brian Kotek]

Or, of course, just be clear and have whatever is using this object call the actual method that is intended. To me, that's a lot more clear than calling context() and sometimes magically getting a list and sometimes magically getting an edit.

[Mark Mandel]

I'd agree with Brian on this one.

For interet's sake - Transfer has an inbuilt library for doing just what you are prescribing.  You can see it here:

http://transfer.riaforge.org/index.cfm?event=page.svnbrowse&path=%2Ftransfer%2Ftrunk%2Fcom/aop

Mark

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

2 Devs from Down Under Podcast

http://www.2ddu.com/

[Chris Blackwell]

Thanks guys,

I think you're right, i'm over complicating things.  I should probably just get the app working and then sort out my urls with routing before they hit the controllers.

@Mark - What was the reasoning for aspect weaving in transfer, rather than spring style proxying?

Cheers, Chris

[Mark Mandel]

I think I wanted to have something standalone you could mix in easily with code without having an external factory.

You can see it in practice here:

http://docs.transfer-orm.com/wiki/Transactions_and_Transfer.cfm

Mark