| I added:
<xsl:for-each select="object/hasOne"> <!--- Delgate get method for <xsl:value-of select="@alias"/> ---> <cffunction name="get<xsl:value-of select="@alias"/>" access="public" output="false" returntype="reactor.project.<xsl:value-of select="/object/@project"/>.Record.<xsl:value-of select="@name"/>Record"> <cfreturn get<xsl:value-of select="@alias"/>Record() /> </cffunction> </xsl:for-each>
to record.base.xml.
Works a treat. You now have getUser() and getUserRecord() methods with getUser() just delegating to getUserRecord().
As far as I'm concerned... problem solved.
The only other thing I might suggest is checking the mapping listed in the config for a project.xsl file (like Eclipse does with .project files... always the same name, always in the root of the project folder) and including that in record.base.xsl if it exists.
Laterz, J
------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion
"That which does not kill me makes me stranger." - Yonah Schmeidler On Mar 24, 2006, at 1:09 PM, Kurt Wiersma wrote: Sorry, it isn't that we aren't willing to help out and provide a patch. I felt it would be best to start the discussion before implementing a patch that might not get accepted. We are certainlly willing to help program a solution, but first I wanted the blessing of the framework owners. In my mind the framework owners are in the best position to decide if and how a solution should be implemented.
--Kurt
On 3/24/06, Jared Rypka-Hauer < [EMAIL PROTECTED]> wrote: I'm not sure I agree with you on that... my rationale for altering core files is this:
"I edited this file, tested it, and here's what I came up with" is the one good way to get adoption (or at least attention) for your suggested change to the framework. If you can't change the XSL, test it, and then say "yeah, works great" then you can't really expect people to take your proposal too seriously. Which is why I proposed it as part interim measure and part test/proof-of-concept.
Sure, for any core file you edit you have to take responsibility for your changes on your end... but once those files have been downloaded and are on my local box they're by no means sacred... at least in terms of helping with the R&D you're proposing. Especially since this is an open-source framework. What prevented you from rolling up some sort of patch and proposing it?
Question: Have you implemented any potential solutions for this problem on your end? Have you actually written code of any kind to try to find a solution? I realize that you wanted to discuss it first, but sometimes charging into the fray with a code sample is far more effective than academic discussion... since the thread was labeled R&D it would be reasonable to expect some R&D had taken place. :)
Just humor me... now it's my turn to play devil's advocate. *steals Seans horns and pitchfork*
Laterz,
------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion
"That which does not kill me makes me stranger." - Yonah Schmeidler On Mar 24, 2006, at 12:49 PM, Kurt Wiersma wrote: I always try to avoid changing actual framework files when ever possible. That is why we are talking about this finding now before we start building this massive app. :) Before I modified framework files I would probably just create a custom method in the Reactor record for now.
--Kurt
On 3/24/06, Jared Rypka-Hauer < [EMAIL PROTECTED] > wrote: Kurt,
As an interim measure, and since you're looking for the answer to this problem be system-wide, why not just edit reactor/xml/project.record.xsl lines 213 and 221 and remove the word "Record" from the method name? At the very least it should allow you to test your suggestion and see how it looks once you've created some objects...
Give it a test?
Laterz, J
------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion
"That which does not kill me makes me stranger." - Yonah Schmeidler On Mar 24, 2006, at 12:41 PM, Kurt Wiersma wrote: I like this solution. When I checked out Transfer I did like how it was setup to put custom methods in the generated object. A per project XSL file would work well for our purposes. I totally understand that you will probably not want to make this extra customization feature of complicate Reactor too much.
--Kurt
On 3/24/06, Sean Corfield < [EMAIL PROTECTED] > wrote: This occurred to me halfway down I-680 on the way to work this morning:
First off, a little context. Reactor goes out of its way to provide
you with *three* versions of each generated file:
- project/foo/Record/xyzRecord.cfc
- mapping/Record/xyzRecord.cfc
- mapping/Record/xyzRecorddbtype.cfc (one for each DB)
The former is inviolate Reactor-generated code and gets recreated
whenever things change or you tell Reactor to do so. The latter two
are created once and are where Reactor expects you to make
customizations.
So Reactor already caters for any customization you might want to do:
it generates shell CFCs for you that it never overwrites.
What Kurt and Shannon want is a customization of Reactor's default
behavior. Reactor "expects" this to happen in the
mapping/Record/xyzRecord.cfc (or the DB-specific ones). So the
Reactor-idiomatic way to address their issue would be to add a custom
method (probably to mapping/Record/xyzRecord.cfc) called getFoo()
which simply contains:
<cfreturn getFooRecord() />
Let's take a quick look at Transfer. It allows you to specify methods
in the XML file (in <![CDATA[ ... ]]> sections) that are automatically
pushed into the generated CFC code.
Hmm, what if Reactor provided a way to do something similar in a more
generic way?
Well, it *almost* does. It has record.base.xsl and record.custom.xsl
where such methods could live. Except that right now, Reactor always
uses the built-in versions from the install.
Proposal:
Provide a way to tell Reactor to use a different XSL file for
base/custom versions (Doug actually mentioned something along these
lines).
I don't know whether it should be per-object or per-project (probably
per-project - then it could just be a directory path to search for the
customized XSL files and, if not found, default to the built-in ones).
This would allow Shannon / Kurt to create a modified record.base.xsl
file that could override the default behavior in a way that I think is
much more idiomatic for the framework. I also think this would be a
much more powerful solution for advanced users of Reactor.
Thoughts?
--
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/
-- 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/
-- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ |
