Brian Kotek's "ColdSpring Mad Science"

[Jamie Jackson]

Would someone please catch me up on what became (or didn't) of BK's
idea* about adding methods and tweaking return types of remote
proxies? (Did this get incorporated into CS?) I'd like to create a
generic advice for my remote proxies to return arrays of VOs for Flex
consumption.

*ColdSpring Mad Science: Injecting Metadata for use in AOP and Proxy Generation
http://www.briankotek.com/blog/index.cfm/2007/7/12/ColdSpring-Mad-Science-Injecting-Metadata-for-use-in-AOP-and-Proxy-Generation

Thanks,
Jamie

[Brian Kotek]

No it's wasn't incorporated into ColdSpring directly but it evolved into my MetadataAwareRemoteFactoryBean and MetadataAwareProxyFactoryBean, which are part of my ColdSpring Utilities RIAForge project at http://coldspringutils.riaforge.org/.

[Jamie Jackson]

Okay, thanks for the clarification. I'll take a look.

[Dennis Clark]

I can't speak of Brian Kotek's work, but IMHO using AOP to return values
incompatible with the target method's returntype is an insanely bad idea.

An important concept in AOP is that any code making calls to objects
subject to weaving should be unaware of what advice (if any) is being
woven. Among other things, this means that a caller can assume that the
type of a value returned from a method call is compatible with the
method's declared returntype. It is quite OK for advice to substitute a
different value of the same type or even an object that is a subclass of
the returntype, but returning a completely different type altogether is
bound to break any code written to call the method before the advice was
woven into it.

Data conversion is more of the realm of the adapter pattern. I recently
found an excellent application of the adapter pattern to handle Flex
data conversion issues within Mark Mandel's Conduit project:

http://www.compoundtheory.com/?action=displayPost&ID=385

The cool thing about Conduit is how it allows you to extend the invoker,
serialiser and deserialiser. For instance, the default invoker simply
instantiates the "source" argument as a CFC and calls the methodName
with given params. One simple step up from the default invoker is one
that uses the "source" argument as a bean name and calls getBean() on a
ColdSpring factory.

If you wanted to do custom data conversion of return values for Flex,
the serialiser in Conduit would be a great place to do it.

Cheers,

-- Dennis

[Mark Mandel]

Woah... so good to see someone is interested in Conduit ;o)

I'm writing up the doco slowly at the moment, but you can also now
apply filters to invokers, serialisers and deserialisers - so if you
want to apply combinations of data transformations or apply them under
different conditions, you can do so in a loosely coupled way very
easily, that than just having to replace the base CFCs.

Mark

On Mon, Mar 2, 2009 at 5:36 AM, Dennis Clark <boom...@gmail.com> wrote:
>
>
> Data conversion is more of the realm of the adapter pattern. I recently
> found an excellent application of the adapter pattern to handle Flex
> data conversion issues within Mark Mandel's Conduit project:
>
> http://www.compoundtheory.com/?action=displayPost&ID=385
>
> The cool thing about Conduit is how it allows you to extend the invoker,
> serialiser and deserialiser. For instance, the default invoker simply
> instantiates the "source" argument as a CFC and calls the methodName
> with given params. One simple step up from the default invoker is one
> that uses the "source" argument as a bean name and calls getBean() on a
> ColdSpring factory.
>
> If you wanted to do custom data conversion of return values for Flex,
> the serialiser in Conduit would be a great place to do it.
>

--
E: mark....@gmail.com
W: www.compoundtheory.com

[Brian Kotek]

While I would say that is true for standard AOP proxy methods, I don't agree when it comes to remote object methods. I don't think the analogy is exact, but when necessary a remote proxy can indeed be thought of as an implementation of the Adapter pattern.

[Dennis Clark]

On Sun, Mar 1, 2009 at 5:27 PM, Brian Kotek <bria...@gmail.com> wrote:

While I would say that is true for standard AOP proxy methods, I don't agree when it comes to remote object methods. I don't think the analogy is exact, but when necessary a remote proxy can indeed be thought of as an implementation of the Adapter pattern.

I believe I understand what you're getting at now. You're using ColdSpring's AOP facilities to construct a proxy designed for remote invocation only: the proxy is not intended to be used by local clients. As long as local clients do not use the proxy they are not affected by modified interface, and as long as remote clients see the proxy and not the local object they are unaware that the proxy's interface differs from that of the local object.

This approach reminds me of implementation inheritance in OO. Implementation inheritance is where a class is extended for the purpose of reusing parts of its implementation, but without the intention of the subclass of ever being a substitute for the superclass. For example, the subclass may intentionally disable methods present in the superclass that are unsupported or undesired. Instances of the subclass cannot be safely used as a substitute for instances of the superclass because a consumer of that superclass expects all the methods defined in the superclass to be available.

Implementation inheritance is a powerful technique for programmers who know how to use it. However it presents a danger for novices who fail to notice how it differs from regular inheritance and begin to believe that substitutability is no longer important when using inheritance. Such novices are bound to run into problems later, and are likely to either severely abuse inheritance or give up on it completely.

Likewise, your approach for using the method interception capabilities in ColdSpring AOP for constructing remote proxy/adapters is fine for programmers who understand what is going on. I hope that it can be made clear that the technique should not be thought of as an example of "real" AOP. After all, AOP is difficult enough for many programmers to understand without throwing in special cases like this.

Cheers,

Dennis
 

[Jorge Loyo]

Brian,

Do you have an example of how you would implement your
"MetadataAwareRemoteFactoryBean" and "MetadataAwareProxyFactoryBean"
in a CFC bind for a cfgrid?

I would to see an example of this since it would eliminate a bunch of
extra methods in most of my services (i.e. get*ForGrid)

Thank you,

[Brian Kotek]

No Jorge, the datagrid or tree binding is one of the few areas where you MUST change the actual method signature of the target method. In what I would consider a poor decision, Adobe chose to implement the grid and tree binding calls in such a way that they require the target method to match a specific signature or it will simply not work. Since there's no way to actually modify the arguments and return type of the remote proxy, you can't use a ColdSpring generated proxy for this type of problem.

That said, it's really not a huge deal. You can write your own remote proxy that you can manage with ColdSpring like you would manage any other normal bean, and you can write an advice that will take the data and translate it into the proper format for a grid or tree binding. So you can still leverage the power of AOP to create a generic converter for this, the only thing you can't do is let ColdSpring generate the actual remote proxy itself.

[Jamie Jackson]

It's interesting that Jorge was heading down the same path that you
had gone down, for the same reasons you did (when you blogged about
mods to ColdSpring for changing method signatures for grids and trees--
http://www.briankotek.com/blog/index.cfm/2007/7/12/ColdSpring-Mad-Science-Injecting-Metadata-for-use-in-AOP-and-Proxy-Generation).
Apparently, according to your reply to Jorge, you had abandoned that
particular part of the approach. (I probably missed some blog post,
where you decided against it.)

Jamie

[Brian Kotek]

Yep it's really one of the few areas that ColdSpring can't handle easily. To be fair, Spring won't let you do this either.

That said, one could probably extend the DefaultXMLBeanFactory (like I did with my DynamicXMLBeanFactory) and add something like this. Though to maintain compatibility with the Spring DTD, the metadata used to alter the signature should probably be specified as a property instead of trying to define it in it's own custom XML element.

[Brian Kotek]

One addition though, this would seem to be a good bit of work just to handle this one situation, and so far this is the only situation I've run into that required changing the signature like this. Since most of the work would (or should) be wrapped up in the advice that actually does the conversion, creating a simple remote proxy component yourself isn't really a very big deal. There are certainly cases where creating your own remote proxy makes sense, and it's important to recognize that ColdSpring's remote proxy generation isn't meant to be a all-encompassing solution for every possible scenario. It's meant to handle the majority of common use cases, which it does, but it's never going to be able to handle every single one.