mach-ii transfer bean filter

[Brian FitzGerald]

Responding to this thread http://tinyurl.com/6kzurq (wow, I just
realized how old it was) and taking Peter's suggestion, I put together
a simple filter which will create your Transfer object for you and
stick it into the event object, much like the event-bean command does.

Basically, it inspects the args in the event object and populates the
Transfer object's matching properties with the correct values so that
you don't have to manually set each property on your own. If you
think it would be of any use to you, you can find the filter here:

http://tinyurl.com/a8m6nb

This is how it would look in your mach-ii.xml config file:

<event-handler event="saveCourse" access="public">
<filter name="transferBeanConverter">
<parameter name="course.Course" value="courseId"/>
</filter>
<notify listener="courseListener" method="saveCourse"/>
<redirect event="manageCourses" args="courseId" persist="true"
persistArgs="result"/>
</event-handler>

Basically you need to specify the name and primary key for the
Transfer object in a parameter passed to the filter. I'm of course
open to any thoughts or suggestions on how it could be improved.

Best,
Brian

ps I also posted this on the Transfer list, so I apologize if you
received this message 2x !

[Jorge Loyo]

Brian,

This may be a stupid question, but what does your "saveCourse" method
look like in your listener?

How do you reference the TransferObject created by your filter?

Thank you

[Jorge Loyo]

Never mind.

> How do you reference the TransferObject created by your filter?

It adds it as an event-arg with the name of the object of the
specified class.

For class "User.user" the event-arg will be called "user".

Thank you,

[Brian FitzGerald]

Hey Jorge, yep you got it.

I hope you find it helpful! It's sort of a work in progress, but it's
been working for me as a solution for the time being. Let me know if
you end up with a modified version that works for your application; I
would love to see the end result.

Best,
Brian

[Jorge Loyo]

Brian,

It has been very helpful... Thank you!

The only thing I did modified was the cfargument type in both
"getTransferBean" and "describeTransferBean" methods. They were set as
"number", but my primary keys are UUIDs and that was generating an
error. I just changed them to "string".

Again, thank you!

[Peter J. Farrell]

Jorge Loyo said the following on 1/26/2009 11:46 AM:

Brian, sounds like sometime you could parameterize in the configuration
time parameters when registering the filter with the framework.

Best,
Peter

[Brian FitzGerald]

Excellent idea Peter, I'm going to play with that and see how I can
improve it.

Thanks!
Brian

[Jorge Loyo]

Quick question, what is the returntype that you have in your listener
methods if the method will return a TransferObject?

Do you have the returntype="transfer.com.TransferObject"? This is what
I am using as opposed to using the {Package}.{Object} defined in the
transfer.xml, but I would like to know if this is fine, or you
recommend something else.

Thanks,

[Brian FitzGerald]

Hey Jorge,

I use decorators for all my transfer objects, even if there is nothing
in them so that I can type them throughout my entire application.
This way, the decorators are right there and ready for you if (and
more likely, when) you need to add additional functionality. Early in
their lives, many of them actually wrap no additional methods to the
Transfer object, and just look like:

<cfcomponent displayname="UserDecorator for MyApp"
extends="myApp.model.utils.AbstractTransferDecorator">
<cffunction name="configure" access="public" returntype="void">
<!--- nothing yet --->
</cffunction>
</cfcomponent>

When you do it like this, you can specify the type as:
"myApp.model.businessObjects.UserDecorator" . If you don't do it this
way, you will need to specify the type of "any", which I don't like,
or specify the type as "transfer.com.TransferObject" as you pointed
out, which I also don't like.

Hope that helps,
Brian

ps, if you decide to use decorators, don't forget to specify the path
to the decorator in the transfer.xml file:

<object name="User" table="user"
decorator="myApp.model.businessObjects.UserDecorator">


---------------

[Jorge Loyo]

Brian,

Awesome. Thank you for your input. I was debating whether or not to
create the decorators for all objects, but you are right, it might be
better to just have them (for the future). I will follow your advice
as I continue to get comfortable with Transfer and Mach-II working
together. So far, I am loving it!!!

Thank you,

[Jorge Loyo]

Another question I just thought of...

If I have the returntype of my service/listener method set to
"transfer.com.TransferObject" then, if I ever change physical location
of my decorators, I will only have to change those paths in the
transfer/coldspring xml, right? As opposed to changing it now in
listener/service methods as well as transfer/coldspring xml's, which
makes maintenance a little bit more tedious and prone to error.

What are your thoughts?
Why do you dislike having the returntype as
"transfer.com.TransferObject"?

[Mark Mandel]

If that is your worry, might as well leave everything as 'any'... duck
type it all! ;o)

Mark

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

[Jorge Loyo]

Mark,

As the transfer creator, what would you recommend? returntype set to
{path.to.decorator}? transfer.com.TransferObject? or Any?
What would you use and why?

I am still in the process of learning a few things and it is always
beneficial to hear from experts and their experiences.

Thank you.

[Brian FitzGerald]

Hey man,

You're right; these two together plus ColdSpring make for a lethal
combination :) I'll be interested to hear your insights as you
progress if you feel like sharing.

All the Best,
Brian

[Matt Williams]

I would recommend some blog reading from the past couple of years.
Typing has been discussed quite a bit.

http://www.google.com/search?q=coldfusion+duck+type

I think more than anything it comes down to your personal programming
preferences for the given application.

Matt

[Jorge Loyo]

Hello All,

I have been using Brian FitzGerald's "transferBeanConverter" filter
with great success. Thank you Brian for this filter.

Now, I've come across a situation that lead me to modify the filter a
little and I wanted to share with you what I did in case someone might
find it useful.

This is a piece of my transfer xml:

<package name="media">
<object name="media" table="tblMedia"
decorator="com.model.media.media">
<id name="media_id" type="numeric" />
<property name="fk_parent" type="numeric" column="fk_parent" />
<property name="file_name" type="string" column="file_name" />
<property name="width" type="numeric" column="width"
nullable="true" />
<property name="height" type="numeric" column="height"
nullable="true" />
<property name="is_preferred" type="numeric"
column="is_preferred" nullable="true" nullvalue="999" />
<manytoone name="Format">
<link to="media.format" column="fk_media_format"/>
</manytoone>
<manytoone name="Type">
<link to="media.type" column="fk_media_type"/>
</manytoone>
</object>

Whenever I needed to edit a media record I used the
transferBeanConverter filter to update the values of the media
transferObject and I could save in that in the database. However, I
realized that the filter was only updating the values of the
properties "<property/>" and not the references to the relationships
defined in the xml "<manytoone>".

I modified the filter to dynamically get the ManyToOne relationships
defined in the xml and get the class path and primary key of that
object. I then look for that column in the event scope, and if found,
I get the new object (i.e changing format and/or type) and update the
reference to that ManyToOne relationship.

Let me know if anyone had a similar situation and whether or not you
would be interested in me giving you the code.

Thank you all,

[Brian FitzGerald]

Hey Jorge,

That sounds like a great improvement! I would love to see the code to
see how you accomplished that and to see if it can work in my app as
well.

Cool stuff
- Brian