Doug, to use Reactor with flex 2 (for remoting or FDS) the cfproperty needs to be set in the component that will go back and foward. I tried with the projectTo but it doesn't work at all.
I totally agree with you that putting the cfproperty tags in the custom goes against everything you already did in reactor. I just asked for this because with the cfproperty there I can use all reactor functions without any additional customization. so 1) Totally agree 2) are there many people customizing customTOs? (but I understand/agree with your point of view) I won't go into too much customization just for FDS because at the end, I'll start having too many plugins and almost not using reactor core objects. Till now I have changed the customTo.xsl so I can deal with that each time I update from SVN. You can close the ticket :) João Fernandes -----Original Message----- From: [EMAIL PROTECTED] on behalf of Doug Hughes Sent: Fri 23-Jun-06 8:37 PM To: João Fernandes Cc: [email protected] Subject: [Reactor for CF] Reactor Ticket #12 João - I was wondering, with regards to Ticket #12 (http://trac.reactorframework.com/reactor/trac.cgi/ticket/12) for Reactor, is it strictly NECESSARY to generate the CFproperty tags in the custom TO (much less at all)? I know that they're useless when generated in the project TOs because Flex doesn't see them for some reason. The problem I have with generating them into the custom TOs are as follows: 1) If the columns in the DB change the cfproperty tags will not be changed or updated. This is opposite of Reactor's normal behavior. 2) If the cfproperties are generated into the custom CFCs then they'd need to go in the DBMS-specific custom objects. This means that the same code could be repeated multiple times. This could create potentially create maintainability problems. My question to you is this: Would it be acceptable to leave these cfproperty tags where they are? As I understand it, right now you're manually copying them to the files where they need to be. Can you continue that? At least past the 1.0 release? Alternatively, you could extend the ReactorFactory and override the getTo method and implement a plugin which would generate the TOs the way you want them. Or, you could just write custom code to copy the cfproperty tags from the project to the dbms-specific custom TOs. If you override the getTo method, but still return a valid abstractTo, then Reactor will automatically use your version to back record objects. (Reactor always uses Reactor to instantiate Reactor objects.) Could any of these be acceptable enough to you that I could close ticket 12 as not being resolved? Thanks, Doug -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Reactor for ColdFusion Mailing List [email protected] Archives at: http://www.mail-archive.com/reactor%40doughughes.net/ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
<<winmail.dat>>
