I agree with Hal. I used to put EVERYTHING in the attributes scope
and leave it at that, but found I still needed to pass variables to
fuseactions called as a custom tag. Then, request scope works well, but
only on an "As Needed" basis. With FB3, I find that most variables set
within a specific fuseaction or circuit can be left in the variables
scope, then passed as attributes to custom tags, if necessary. I do,
however, leave some variables as request scope, such as "request.self"
and "request.dsn". I use these throughout an app and within custom tags,
so they stay availablethroughout without any extra coding.Bob Krieger -----Original Message----- From: hal helms [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 7:10 AM To: [EMAIL PROTECTED] Subject: RE: FB3, CF MX and fuseaction variable I would recommend placing them in the local "variables" scope. -----Original Message----- From: Andy [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 4:38 AM To: [EMAIL PROTECTED] Subject: RE: FB3, CF MX and fuseaction variable I store XFAs in the request scope ... since I saw the wireframe tool generating code this way I assumed it was standard. Is it part of FB3 conventions that I should be storing these in local scope ? Andy. Douglas Smith wrote: > XFA's may be a problem since since they are, by convention, local > variable with a dot in their name [XFA.ExitName]. Of course, they > could easily > be > renamed as [XFA_ExitName]. When running your FB app in MX, just do a > global search and replace for "XFA." and replace it with "XFA_" > ==^================================================================ 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 ==^================================================================
