On 3/24/06, João Fernandes <[EMAIL PROTECTED]> wrote: > Sean you should take a look to the generated files.
I reviewed the code gen when Nimer was writing the wizards :) > The Fill method in fact calls the DAO.read function that is nothing else than > Array of TO's > Get is an instance of a TO. > sync gets an array of changed objects and returns an array. > and count...well, the total of records (TO) returned. Yup, that's how the assembler interacts with the bean / DAO stuff. Hence if you write an assembler (fill() / get() / sync() / count()) that wraps Reactor "record" objects *and* you add <cfproperty/> tags to the "record" objects and treat them as beans in the above equation, it'll work. > I Couldn't wait till monday so I just connected remotly and added those > properties in the mssql.cfc and guess what? It works !!!!!! So you have a custom assembler that uses Reactor methods on the bean for persistence instead of the DAO, yes? > I'll have just to change the customTo.xsl so it generates also those > properties like in the baseTo.xsl. Hmm, OK, you're taking a different approach to how I would do the integration. I would use Reactor "record" objects and add <cfproperty/> to those and write a custom assembler that didn't need the DAO, just operated on the "record" objects directly - and used a gateway object for the fill() method. -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
