Another way is to include the functions on the
client side.
<script language="javascript" source="/javascript/something.js">
This is what I normally do, and I make it part of
the dsp file, since javascript functions are dependencies
of the dsp file, not the fusebox itself.
If a function is specific to a dsp file, I just hard code
it into the file itself.
Patrick
> -----Original Message-----
> From: George Kaytor [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 23, 2001 9:47 PM
> To: Fusebox
> Subject: Re: Javascript fuse style question
>
>
> This may seem a simple question but.... would it be easier to
> cfinclude your
> javascript functions inside your dsp pages? I also keep a jsp
> folder with my
> javascript functions, but refer to them in my index.cfm. I just cfinclude
> them in the appropriate display page.
>
> -george
>
>
> >From: Kevin Bridges <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: Fusebox <[EMAIL PROTECTED]>
> >Subject: Javascript fuse style question
> >Date: Fri, 23 Feb 2001 14:19:20 -0700
> >
> >We have a pretty large amount of javascript that is in some of
> the apps we
> >are doing. Most of the functions are conditional and not all
> will be used
> >in every scenario, but they all need to be accessible to the
> page. A good
> >deal of the functions need to hit a hidden frame to perform queries and
> >return specific information. Basically what we were developing were huge
> >blocks of javascript functions inside of our fusebox pages that could
> >potentially take a good deal of time to trouble shoot ... seemed
> to counter
> >the simplicity of a fusebox app.
> >
> >Soooo came up with the idea of creating a jsp directory inside
> the fuse to
> >store jsp_whatever.cfm where a jsp_ page stores a single javascript
> >function. All we need now is this function:
> >
> >function CallJavaScript(x) {
> > Location =
> >"index.cfm?FuseAction=CallJavaScript&<cfoutput>#client.urltoken#<
> /cfoutput>&
> >Function=" + x;
> > parent.JavaScriptFrame.location = Location;
> >}
> >
> >it hits the hidden frame and calls the necessary function that does
> >whatever
> >processing on the parent frame we need. A function can even call
> >additional
> >functions as needed. When we hit the CallJavaScript value in our main
> >switch statement we simply open another switch that checks
> >attributes.Function and calls the appropriate jsp_ file.
> >
> >This works great and keeps the code manageable and more fusebox like ...
> >however it also generates additional hits to the server and somewhat
> >negates
> >the beauty of the true client side pre-processing. I was wondering if
> >anyone had any opinions or concerns about this method of doing
> this or any
> >ideas about how this might slow down an application in a production
> >environment.
> >
> >Thanks!
> >
> >Kevin Bridges
> >
> >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
