> Well, there *is* one other possible issue that springs to mind. FB is > already an include-happy approach to CF... I spent an hour or two going > through FusionScript last night, and I found myself thinking, "Sheesh, > there go another couple hundred milliseconds to code infrastructure." :)
Yes, the structure of of it has a large number of includes. This allows for you to change the core engine code for specific sections easily without effecting other portions of it. It also improves performance by only including the functionality you are actually using in a specific page. With v1.0 beta, you can also cache your scripts for specified time periods, bringing your processing time for them to practically nil. Once you have finalized your script, there are few reasons NOT to cache you script. Even if you are <cfoutput>'ing some dynamic variables, you can place those definitions in a separate FusionScript code block and only leave that code block un cached. FusionScript is also very dynamic and there are a number of tricks you can do to increase your processing time depending on what you are doing. For example, you can cut your processing time down an amazing amount by placing your library include statement outside a fusionscript code block and into a regular <script> block. Place them inside your actual code block only if you are going to cache that block. > Can you give a specific example? A good example is the little activeServer script on the homepage of the FusionScript web site. You have two separate pages, a client page with FusionScript that generates the script to call to the server, and the server page that receives and fulfills those requests. When you make a call to the server, you pass a page, an optional codebase, and custom attributes for passing your data to it. There is currently a way to specify a fuseaction simply by using a custom attribute, but with the next release, that data will be encrypted and scrambled, making it impossible to specify such a param. The server page also doesn't seem to fit into the FB model that I can tell. I suppose you could simply make it a regular fuse action or something, but then again you have the issue mentioned above. > Oh, I'm sure it's quite possible... but why would anyone bother? :) >From what I have been told by some reasonably strong FB resources, FusionScript would not fit in the FB model due to its needs and the fact that FB isn't really built to support development tools such as this - realize there are no FusionScript "pages" - its all tags and API calls. I wouldn't port it into FB regardless because I would like to leave the API open to be changed to those whom are not familiar with FB. FusionScript actually has its own API to allow it to do all the processing it does in one cycle of the tags. I have actually had requests to rip out the API itself and document it for others to develop similar applications. Once you get into the FusionScript API, you will realize how flexible it is for developing tools such as this - its pretty fascinating. > Hey, I'll do the latter anyway... but that's just me. :) =) hehe. Nate Nielsen FusionScript DevTeam [EMAIL PROTECTED] [EMAIL PROTECTED] Develop CF apps that talk to the server without page reloads ! Create client functionality with CF syntax ! www.FusionScript.com ----- Original Message ----- From: "Roger B." <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 16, 2002 9:29 AM Subject: RE: Using FuseBox with FusionScript - help? > > Nate Nielsen wrote: > > Thanks, so far the responses have been very positive. > > They should be. It's a very ambitious project, IMO. > > > FusionScript will never be tied to one specific framework, methodology, > > etc. > > I didn't mean to suggest otherwise. What I was getting at is that, from > the POV of FusionScript, an FB app shouldn't really look any different > than a non-FB app. > > About the only big FB/FS problem I see is for folks using nested > circuits who don't have access to the custom tags directory... they'd > basically need to dump copies of the FS tags into every circuit. CFMX's > CFIMPORT solves that problem, though, so it probably isn't worth > worrying about much. > > Well, there *is* one other possible issue that springs to mind. FB is > already an include-happy approach to CF... I spent an hour or two going > through FusionScript last night, and I found myself thinking, "Sheesh, > there go another couple hundred milliseconds to code infrastructure." :) > > > I'm not looking for someone to convert the FusionScript API into FuseBox > > - I > > am convinced it isn't possible... > > Oh, I'm sure it's quite possible... but why would anyone bother? :) > > > ...current FB documenation doesn't quite seem to fit or apply. > > Can you give a specific example? > > > It would be nice to say "There is a section of documentation provided > > about > > how FusionScript can fit appropriately into your FB apps" rather than - > > "I > > am still trying to get some specs from the FB folks to provide for you, > > for > > now - make up your own FB integration rules if you want" > > Hey, I'll do the latter anyway... but that's just me. :) > > > -- > Roger > > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
