Loading ...
Sorry, an error occurred while loading the content.

advice on per fuseaction session scope

Expand Messages
  • Mike Haggerty
    Looking for some advice: There are a number of fuseactions in apps that I develop where I want to retain some sense of state. For example, if a user is on a
    Message 1 of 13 , May 2 8:33 AM
    • 0 Attachment
      Looking for some advice:

      There are a number of fuseactions in apps that I develop where I want to retain some sense of state.  For example, if a user is on a list page, and they filter the list, and sort the list, then go off and play somewhere else, when they return to the list page, it is still in the same state as when they left.

      I have been making use of the session scope to do this, but I'm trying to figure out a way to make things a little smoother.  I had this idea this morning, and wanted to bounce it off some more knowledgeable folk.

      -----
      Global Prefuseaction:
      <cfset myself = session['thisfa'] /> <!--- use myfusebox to determine name of current fuseaction request --->

      Fuseaction:
      <cfset myself.sort = "name" />
      <cfset myself.listpage = "4" />
      <!--- state info that can change on user input --->

      Global Postfuseaction:
      <cfset session['thisfa'] = myself />
      -----

      Is this extremely dangerous?  Way too many system resources?  Even if myself is an empty struct in most fuseactions, will it still be taking up way too much memory?  Of course this all depends on resources available, and number of current users on system, etc., but are there any blaring red lights to an approach like this that I might be overlooking?

      Thanks for any input!
      Mike


      Ryan J. Heldt wrote:

      Sid-

      One thing I usually do is create another folder (I call mine /external/ but you can name it whatever you like) that has it's own Application. cfc (or it cold be Application. cfm) file, but has the same application name as the main application so all your shared scopes are there, but it doesn't extend fusebox.Application . It usually works pretty well, but it's not perfect. The only real problem I have with it is remembering to change both application names if I need to rename the application for some reason.

      Thanks!
      Ryan

      s1dw00d wrote:

      When using Application. cfc, how can I bypass the framework when
      requesting a .cfm page?

      I'm migrating an older fusebox application to 5.5 using
      Application. cfc. There are a few "legacy" requests that bypass the
      framework and they need to continue to do so for the time being. I can
      do this no problem using Application. cfm but I would like to use the
      Application. cfc if at all possible.

      Cheers,

      Sid


      -- 
      Michael Haggerty
      Internet Applications Developer
      SiteVision, Inc.
      <e>mike@...</e>
      <p>540.343.8322 x116</p>
    • Seth Johnson
      How about shoving those values in a session struct or a user s cookie? I don t think myself will persist across a user s session unless you prepend it like so:
      Message 2 of 13 , May 2 9:08 AM
      • 0 Attachment
         
        How about shoving those values in a session struct or a user's cookie?
         
        I don't think myself will persist across a user's session unless you prepend it like so: session.myself.sort or cookie.sort
         
        Seth
         
         
        ----- Original Message -----
        Sent: Friday, May 02, 2008 11:33 AM
        Subject: [fusebox5] advice on per fuseaction session scope

        Looking for some advice:

        There are a number of fuseactions in apps that I develop where I want to retain some sense of state.  For example, if a user is on a list page, and they filter the list, and sort the list, then go off and play somewhere else, when they return to the list page, it is still in the same state as when they left.

        I have been making use of the session scope to do this, but I'm trying to figure out a way to make things a little smoother.  I had this idea this morning, and wanted to bounce it off some more knowledgeable folk.

        -----
        Global Prefuseaction:
        <cfset myself = session['thisfa' ] /> <!--- use myfusebox to determine name of current fuseaction request --->

        Fuseaction:
        <cfset myself.sort = "name" />
        <cfset myself.listpage = "4" />
        <!--- state info that can change on user input --->

        Global Postfuseaction:
        <cfset session['thisfa' ] = myself />
        -----

        Is this extremely dangerous?  Way too many system resources?  Even if myself is an empty struct in most fuseactions, will it still be taking up way too much memory?  Of course this all depends on resources available, and number of current users on system, etc., but are there any blaring red lights to an approach like this that I might be overlooking?

        Thanks for any input!
        Mike


        Ryan J. Heldt wrote:

        Sid-

        One thing I usually do is create another folder (I call mine /external/ but you can name it whatever you like) that has it's own Application. cfc (or it cold be Application. cfm) file, but has the same application name as the main application so all your shared scopes are there, but it doesn't extend fusebox.Application . It usually works pretty well, but it's not perfect. The only real problem I have with it is remembering to change both application names if I need to rename the application for some reason.

        Thanks!
        Ryan

        s1dw00d wrote:

        When using Application. cfc, how can I bypass the framework when
        requesting a .cfm page?

        I'm migrating an older fusebox application to 5.5 using
        Application. cfc. There are a few "legacy" requests that bypass the
        framework and they need to continue to do so for the time being. I can
        do this no problem using Application. cfm but I would like to use the
        Application. cfc if at all possible.

        Cheers,

        Sid


        -- 
        Michael Haggerty
        Internet Applications Developer
        SiteVision, Inc.
        <e>mike@sitevision. com</e>
        <p>540.343.8322 x116</p>

      • Mike Haggerty
        Myself is just an intermediary variable to hold session data. I load it with data from the session struct in the global prefuseaction, and pop it back into
        Message 3 of 13 , May 2 9:21 AM
        • 0 Attachment
          Myself is just an intermediary variable to hold session data.  I load it with data from the session struct in the global prefuseaction, and pop it back into the session struct in the global postfuseaction.  It's just a cleaner way of having to reference session['#application.myfusebox().getCurrentFuseaction()#'] (or whatever function calls will get me the current FA) in the fuseaction.  That code would get real ugly real quick.

          I was doing something along the lines of session.myself.sort, but then if I used session.myself.sort in the foo list page, and used the session.myself.sort variable in the bar list page, when I go back to the foo list page it would not have the same state.  So I started thinking about using session.fooState.sort in the foo fuseaction and session.barState.sort in the bar fuseaction, but then thought....why not just make a site wide solution so that every fuseaction has their own session struct available.

          Hopefully that makes sense.

          Mike

          Seth Johnson wrote:

           
          How about shoving those values in a session struct or a user's cookie?
           
          I don't think myself will persist across a user's session unless you prepend it like so: session.myself. sort or cookie.sort
           
          Seth
           
           
          ----- Original Message -----
          Sent: Friday, May 02, 2008 11:33 AM
          Subject: [fusebox5] advice on per fuseaction session scope

          Looking for some advice:

          There are a number of fuseactions in apps that I develop where I want to retain some sense of state.  For example, if a user is on a list page, and they filter the list, and sort the list, then go off and play somewhere else, when they return to the list page, it is still in the same state as when they left.

          I have been making use of the session scope to do this, but I'm trying to figure out a way to make things a little smoother.  I had this idea this morning, and wanted to bounce it off some more knowledgeable folk.

          -----
          Global Prefuseaction:
          <cfset myself = session['thisfa' ] /> <!--- use myfusebox to determine name of current fuseaction request --->

          Fuseaction:
          <cfset myself.sort = "name" />
          <cfset myself.listpage = "4" />
          <!--- state info that can change on user input --->

          Global Postfuseaction:
          <cfset session['thisfa' ] = myself />
          -----

          Is this extremely dangerous?  Way too many system resources?  Even if myself is an empty struct in most fuseactions, will it still be taking up way too much memory?  Of course this all depends on resources available, and number of current users on system, etc., but are there any blaring red lights to an approach like this that I might be overlooking?

          Thanks for any input!
          Mike


          Ryan J. Heldt wrote:

          Sid-

          One thing I usually do is create another folder (I call mine /external/ but you can name it whatever you like) that has it's own Application. cfc (or it cold be Application. cfm) file, but has the same application name as the main application so all your shared scopes are there, but it doesn't extend fusebox.Application . It usually works pretty well, but it's not perfect. The only real problem I have with it is remembering to change both application names if I need to rename the application for some reason.

          Thanks!
          Ryan

          s1dw00d wrote:

          When using Application. cfc, how can I bypass the framework when
          requesting a .cfm page?

          I'm migrating an older fusebox application to 5.5 using
          Application. cfc. There are a few "legacy" requests that bypass the
          framework and they need to continue to do so for the time being. I can
          do this no problem using Application. cfm but I would like to use the
          Application. cfc if at all possible.

          Cheers,

          Sid


          -- 
          Michael Haggerty
          Internet Applications Developer
          SiteVision, Inc.
          <e>mike@sitevision. com</e>
          <p>540.343.8322 x116</p>

          -- 
          Michael Haggerty
          Internet Applications Developer
          SiteVision, Inc.
          <e>mike@...</e>
          <p>540.343.8322 x116</p>
        • Sean Corfield
          ... By convention, myself is typically used for the URL to index.cfm (with the fuseaction stub). I think you need to pick a better name. What you re trying to
          Message 4 of 13 , May 2 9:40 AM
          • 0 Attachment
            On May 2, 2008, at 8:33 AM, Mike Haggerty wrote:
            > Global Prefuseaction:

            > <cfset myself = session['thisfa'] /> <!--- use myfusebox to
            > determine name of current fuseaction request --->

            By convention, myself is typically used for the URL to index.cfm (with
            the fuseaction stub). I think you need to pick a better name. What
            you're trying to replicate here is often called "flash scope" or "view
            state".

            Otherwise I think it's fairly reasonable.

            > Is this extremely dangerous?

            Dangerous how?

            > Way too many system resources?

            One struct per user. That's negligible.

            > Even if myself is an empty struct in most fuseactions, will it still
            > be taking up way too much memory?

            Do you have millions of concurrent users? Probably not so memory will
            not be an issue. adobe.com puts a lot of stuff in session scope and
            has something like 40,000 concurrent sessions per server instance.

            Sean A Corfield -- (904) 302-SEAN
            An Architect's View -- http://corfield.org/

            "If you're not annoying somebody, you're not really alive."
            -- Margaret Atwood
          • Seth Johnson
            Sorry, I should have looked more closely at your solution. In my apps I set a session.user struct and then append whatever session vars I want that user to
            Message 5 of 13 , May 2 9:41 AM
            • 0 Attachment
               
              Sorry, I should have looked more closely at your solution.  In my apps I set a session.user struct and then append whatever session vars I want that user to have access to.  Then when they log out I kill their session struct.  Otherwise you would have to loop through all of the fa sessions that may have been created to destroy them.
               
              ----- Original Message -----
              Sent: Friday, May 02, 2008 12:21 PM
              Subject: Re: [fusebox5] advice on per fuseaction session scope

              Myself is just an intermediary variable to hold session data.  I load it with data from the session struct in the global prefuseaction, and pop it back into the session struct in the global postfuseaction.  It's just a cleaner way of having to reference session['#applicati on.myfusebox( ).getCurrentFuse action()# '] (or whatever function calls will get me the current FA) in the fuseaction.  That code would get real ugly real quick.

              I was doing something along the lines of session.myself. sort, but then if I used session.myself. sort in the foo list page, and used the session.myself. sort variable in the bar list page, when I go back to the foo list page it would not have the same state.  So I started thinking about using session.fooState. sort in the foo fuseaction and session.barState. sort in the bar fuseaction, but then thought....why not just make a site wide solution so that every fuseaction has their own session struct available.

              Hopefully that makes sense.

              Mike

              Seth Johnson wrote:

               
              How about shoving those values in a session struct or a user's cookie?
               
              I don't think myself will persist across a user's session unless you prepend it like so: session.myself. sort or cookie.sort
               
              Seth
               
               
              ----- Original Message -----
              Sent: Friday, May 02, 2008 11:33 AM
              Subject: [fusebox5] advice on per fuseaction session scope

              Looking for some advice:

              There are a number of fuseactions in apps that I develop where I want to retain some sense of state.  For example, if a user is on a list page, and they filter the list, and sort the list, then go off and play somewhere else, when they return to the list page, it is still in the same state as when they left.

              I have been making use of the session scope to do this, but I'm trying to figure out a way to make things a little smoother.  I had this idea this morning, and wanted to bounce it off some more knowledgeable folk.

              -----
              Global Prefuseaction:
              <cfset myself = session['thisfa' ] /> <!--- use myfusebox to determine name of current fuseaction request --->

              Fuseaction:
              <cfset myself.sort = "name" />
              <cfset myself.listpage = "4" />
              <!--- state info that can change on user input --->

              Global Postfuseaction:
              <cfset session['thisfa' ] = myself />
              -----

              Is this extremely dangerous?  Way too many system resources?  Even if myself is an empty struct in most fuseactions, will it still be taking up way too much memory?  Of course this all depends on resources available, and number of current users on system, etc., but are there any blaring red lights to an approach like this that I might be overlooking?

              Thanks for any input!
              Mike


              Ryan J. Heldt wrote:

              Sid-

              One thing I usually do is create another folder (I call mine /external/ but you can name it whatever you like) that has it's own Application. cfc (or it cold be Application. cfm) file, but has the same application name as the main application so all your shared scopes are there, but it doesn't extend fusebox.Application . It usually works pretty well, but it's not perfect. The only real problem I have with it is remembering to change both application names if I need to rename the application for some reason.

              Thanks!
              Ryan

              s1dw00d wrote:

              When using Application. cfc, how can I bypass the framework when
              requesting a .cfm page?

              I'm migrating an older fusebox application to 5.5 using
              Application. cfc. There are a few "legacy" requests that bypass the
              framework and they need to continue to do so for the time being. I can
              do this no problem using Application. cfm but I would like to use the
              Application. cfc if at all possible.

              Cheers,

              Sid


              -- 
              Michael Haggerty
              Internet Applications Developer
              SiteVision, Inc.
              <e>mike@sitevision. com</e>
              <p>540.343.8322 x116</p>

              -- 
              Michael Haggerty
              Internet Applications Developer
              SiteVision, Inc.
              <e>mike@sitevision. com</e>
              <p>540.343.8322 x116</p>

            • Mike Haggerty
              Ahh yes...I was wondering why myself sounded so familiar. Definitely need to pick a better var name. I m not developing for anywhere near 40k users, so it s
              Message 6 of 13 , May 2 9:53 AM
              • 0 Attachment
                Ahh yes...I was wondering why myself sounded so familiar.  Definitely need to pick a better var name.

                I'm not developing for anywhere near 40k users, so it's good to know I won't be overloading the machine.

                So there's no view state akin to this built into fb55 that I am overlooking?

                If not, would this be something I could incorporate into a plugin so others could use it?  I guess there are the preFuseaction and postFuseaction plugin phases.  Can plugins be written as CFCs, or do they have to be vanilla cfm files.  I guess I could always call a cfc function from the template cfm file.

                Thanks!
                Mike


                Sean Corfield wrote:

                On May 2, 2008, at 8:33 AM, Mike Haggerty wrote:
                > Global Prefuseaction:

                > <cfset myself = session['thisfa' ] /> <!--- use myfusebox to
                > determine name of current fuseaction request --->

                By convention, myself is typically used for the URL to index.cfm (with
                the fuseaction stub). I think you need to pick a better name. What
                you're trying to replicate here is often called "flash scope" or "view
                state".

                Otherwise I think it's fairly reasonable.

                > Is this extremely dangerous?

                Dangerous how?

                > Way too many system resources?

                One struct per user. That's negligible.

                > Even if myself is an empty struct in most fuseactions, will it still
                > be taking up way too much memory?

                Do you have millions of concurrent users? Probably not so memory will
                not be an issue. adobe.com puts a lot of stuff in session scope and
                has something like 40,000 concurrent sessions per server instance.

                Sean A Corfield -- (904) 302-SEAN
                An Architect's View -- http://corfield. org/

                "If you're not annoying somebody, you're not really alive."
                -- Margaret Atwood


                -- 
                Michael Haggerty
                Internet Applications Developer
                SiteVision, Inc.
                <e>mike@...</e>
                <p>540.343.8322 x116</p>
              • Mike Haggerty
                Great idea. Thanks! ... -- Michael Haggerty Internet Applications Developer SiteVision, Inc. mike@sitevision.com 540.343.8322 x116
                Message 7 of 13 , May 2 9:55 AM
                • 0 Attachment
                  Great idea.

                  Thanks!

                  Seth Johnson wrote:

                   
                  Sorry, I should have looked more closely at your solution.  In my apps I set a session.user struct and then append whatever session vars I want that user to have access to.  Then when they log out I kill their session struct.  Otherwise you would have to loop through all of the fa sessions that may have been created to destroy them.
                   
                  ----- Original Message -----
                  Sent: Friday, May 02, 2008 12:21 PM
                  Subject: Re: [fusebox5] advice on per fuseaction session scope

                  Myself is just an intermediary variable to hold session data.  I load it with data from the session struct in the global prefuseaction, and pop it back into the session struct in the global postfuseaction.  It's just a cleaner way of having to reference session['#applicati on.myfusebox( ).getCurrentFuse action()# '] (or whatever function calls will get me the current FA) in the fuseaction.  That code would get real ugly real quick.

                  I was doing something along the lines of session.myself. sort, but then if I used session.myself. sort in the foo list page, and used the session.myself. sort variable in the bar list page, when I go back to the foo list page it would not have the same state.  So I started thinking about using session.fooState. sort in the foo fuseaction and session.barState. sort in the bar fuseaction, but then thought....why not just make a site wide solution so that every fuseaction has their own session struct available.

                  Hopefully that makes sense.

                  Mike

                  Seth Johnson wrote:

                   
                  How about shoving those values in a session struct or a user's cookie?
                   
                  I don't think myself will persist across a user's session unless you prepend it like so: session.myself. sort or cookie.sort
                   
                  Seth
                   
                   
                  ----- Original Message -----
                  Sent: Friday, May 02, 2008 11:33 AM
                  Subject: [fusebox5] advice on per fuseaction session scope

                  Looking for some advice:

                  There are a number of fuseactions in apps that I develop where I want to retain some sense of state.  For example, if a user is on a list page, and they filter the list, and sort the list, then go off and play somewhere else, when they return to the list page, it is still in the same state as when they left.

                  I have been making use of the session scope to do this, but I'm trying to figure out a way to make things a little smoother.  I had this idea this morning, and wanted to bounce it off some more knowledgeable folk.

                  -----
                  Global Prefuseaction:
                  <cfset myself = session['thisfa' ] /> <!--- use myfusebox to determine name of current fuseaction request --->

                  Fuseaction:
                  <cfset myself.sort = "name" />
                  <cfset myself.listpage = "4" />
                  <!--- state info that can change on user input --->

                  Global Postfuseaction:
                  <cfset session['thisfa' ] = myself />
                  -----

                  Is this extremely dangerous?  Way too many system resources?  Even if myself is an empty struct in most fuseactions, will it still be taking up way too much memory?  Of course this all depends on resources available, and number of current users on system, etc., but are there any blaring red lights to an approach like this that I might be overlooking?

                  Thanks for any input!
                  Mike


                  Ryan J. Heldt wrote:

                  Sid-

                  One thing I usually do is create another folder (I call mine /external/ but you can name it whatever you like) that has it's own Application. cfc (or it cold be Application. cfm) file, but has the same application name as the main application so all your shared scopes are there, but it doesn't extend fusebox.Application . It usually works pretty well, but it's not perfect. The only real problem I have with it is remembering to change both application names if I need to rename the application for some reason.

                  Thanks!
                  Ryan

                  s1dw00d wrote:

                  When using Application. cfc, how can I bypass the framework when
                  requesting a .cfm page?

                  I'm migrating an older fusebox application to 5.5 using
                  Application. cfc. There are a few "legacy" requests that bypass the
                  framework and they need to continue to do so for the time being. I can
                  do this no problem using Application. cfm but I would like to use the
                  Application. cfc if at all possible.

                  Cheers,

                  Sid


                  -- 
                  Michael Haggerty
                  Internet Applications Developer
                  SiteVision, Inc.
                  <e>mike@sitevision. com</e>
                  <p>540.343.8322 x116</p>

                  -- 
                  Michael Haggerty
                  Internet Applications Developer
                  SiteVision, Inc.
                  <e>mike@sitevision. com</e>
                  <p>540.343.8322 x116</p>

                  -- 
                  Michael Haggerty
                  Internet Applications Developer
                  SiteVision, Inc.
                  <e>mike@...</e>
                  <p>540.343.8322 x116</p>
                • Mike
                  This is what I d do: ...
                  Message 8 of 13 , May 2 10:16 AM
                  • 0 Attachment
                    This is what I'd do:

                    <circuit access="public" xmlns:remember="remember/">

                    <fuseaction name="list" remember:attributes="CategoryID,SortOrder">
                    ...
                    </fuseaction>

                    </circuit>


                    Then make a preFuseaction plugin:

                    <cfif not StructKeyExists(session,'rememberedAttributes')>
                    <cfset session.rememberedAttributes = StructNew()>
                    </cfif>
                    <cfset theAttrs =
                    myFusebox.getCurrentFuseaction().getCustomAttributes('remember')>
                    <cfif StructKeyExists(theAttrs,'attributes')>
                    <cfloop index="theVar" list="#theAttrs['attributes']#">
                    <cfif StructKeyExists(attributes,theVar)>
                    <cfset session.rememberedAttributes[theVar] = attributes[theVar]>
                    <cfelseif StructKeyExists(session.rememberedAttributes,theVar)>
                    <cfset attributes[theVar] = session.rememberedAttributes[theVar]>
                    </cfif>
                    </cfloop>
                    </cfif>


                    I'm doing something similar right now in a storefront application I'm
                    writing in PHPFB5 and it works great. The first time a user accesses a
                    fuseaction they get the default view because neither var is set. If
                    they filter or sort the list they have to submit a form or click on a
                    link and the attributes scope is set, which populates the session var.
                    The next time the user access the fuseaction the session vars are set,
                    which populates the attributes vars.

                    HTH

                    Mike
                    www.fusebuilder.net


                    --- In fusebox5@yahoogroups.com, Mike Haggerty <mike@...> wrote:
                    >
                    > Great idea.
                    >
                    > Thanks!
                    >
                    > Seth Johnson wrote:
                    > >
                    > >
                    > > Sorry, I should have looked more closely at your solution. In my
                    apps
                    > > I set a session.user struct and then append whatever session vars I
                    > > want that user to have access to. Then when they log out I kill
                    their
                    > > session struct. Otherwise you would have to loop through all of the
                    > > fa sessions that may have been created to destroy them.
                    > >
                    > >
                    > > ----- Original Message -----
                    > > *From:* Mike Haggerty <mailto:mike@...>
                    > > *To:* fusebox5@yahoogroups.com <mailto:fusebox5@yahoogroups.com>
                    > > *Sent:* Friday, May 02, 2008 12:21 PM
                    > > *Subject:* Re: [fusebox5] advice on per fuseaction session scope
                    > >
                    > > Myself is just an intermediary variable to hold session data. I
                    > > load it with data from the session struct in the global
                    > > prefuseaction, and pop it back into the session struct in the
                    > > global postfuseaction. It's just a cleaner way of having to
                    > > reference
                    > > session['#application.myfusebox().getCurrentFuseaction()#'] (or
                    > > whatever function calls will get me the current FA) in the
                    > > fuseaction. That code would get real ugly real quick.
                    > >
                    > > I was doing something along the lines of session.myself.sort, but
                    > > then if I used session.myself.sort in the foo list page, and used
                    > > the session.myself.sort variable in the bar list page, when I go
                    > > back to the foo list page it would not have the same state. So I
                    > > started thinking about using session.fooState.sort in the foo
                    > > fuseaction and session.barState.sort in the bar fuseaction, but
                    > > then thought....why not just make a site wide solution so that
                    > > every fuseaction has their own session struct available.
                    > >
                    > > Hopefully that makes sense.
                    > >
                    > > Mike
                    > >
                    > > Seth Johnson wrote:
                    > >
                    > >>
                    > >> How about shoving those values in a session struct or a user's
                    > >> cookie?
                    > >>
                    > >> I don't think myself will persist across a user's session unless
                    > >> you prepend it like so: session.myself.sort or cookie.sort
                    > >>
                    > >> Seth
                    > >>
                    > >>
                    > >>
                    > >> ----- Original Message -----
                    > >> *From:* Mike Haggerty <mailto:mike@...>
                    > >> *To:* fusebox5@yahoogroups.com
                    <mailto:fusebox5@yahoogroups.com>
                    > >> *Sent:* Friday, May 02, 2008 11:33 AM
                    > >> *Subject:* [fusebox5] advice on per fuseaction session scope
                    > >>
                    > >> Looking for some advice:
                    > >>
                    > >> There are a number of fuseactions in apps that I develop
                    > >> where I want to retain some sense of state. For example, if
                    > >> a user is on a list page, and they filter the list, and sort
                    > >> the list, then go off and play somewhere else, when they
                    > >> return to the list page, it is still in the same state as
                    > >> when they left.
                    > >>
                    > >> I have been making use of the session scope to do this, but
                    > >> I'm trying to figure out a way to make things a little
                    > >> smoother. I had this idea this morning, and wanted to bounce
                    > >> it off some more knowledgeable folk.
                    > >>
                    > >> -----
                    > >> Global Prefuseaction:
                    > >> <cfset myself = session['thisfa'] /> <!--- use myfusebox to
                    > >> determine name of current fuseaction request --->
                    > >>
                    > >> Fuseaction:
                    > >> <cfset myself.sort = "name" />
                    > >> <cfset myself.listpage = "4" />
                    > >> <!--- state info that can change on user input --->
                    > >>
                    > >> Global Postfuseaction:
                    > >> <cfset session['thisfa'] = myself />
                    > >> -----
                    > >>
                    > >> Is this extremely dangerous? Way too many system resources?
                    > >> Even if myself is an empty struct in most fuseactions, will
                    > >> it still be taking up way too much memory? Of course this
                    > >> all depends on resources available, and number of current
                    > >> users on system, etc., but are there any blaring red lights
                    > >> to an approach like this that I might be overlooking?
                    > >>
                    > >> Thanks for any input!
                    > >> Mike
                    > >>
                    > >>
                    > >> Ryan J. Heldt wrote:
                    > >>
                    > >>> Sid-
                    > >>>
                    > >>> One thing I usually do is create another folder (I call mine
                    > >>> /external/ but you can name it whatever you like) that has
                    > >>> it's own Application.cfc (or it cold be Application.cfm)
                    > >>> file, but has the same application name as the main
                    > >>> application so all your shared scopes are there, but it
                    > >>> doesn't extend fusebox.Application. It usually works pretty
                    > >>> well, but it's not perfect. The only real problem I have
                    > >>> with it is /remembering /to change both application names if
                    > >>> I need to rename the application for some reason.
                    > >>>
                    > >>> Thanks!
                    > >>> Ryan
                    > >>>
                    > >>> s1dw00d wrote:
                    > >>>
                    > >>>> When using Application.cfc, how can I bypass the
                    framework when
                    > >>>> requesting a .cfm page?
                    > >>>>
                    > >>>> I'm migrating an older fusebox application to 5.5 using
                    > >>>> Application.cfc. There are a few "legacy" requests that
                    > >>>> bypass the
                    > >>>> framework and they need to continue to do so for the time
                    > >>>> being. I can
                    > >>>> do this no problem using Application.cfm but I would like
                    > >>>> to use the
                    > >>>> Application.cfc if at all possible.
                    > >>>>
                    > >>>> Cheers,
                    > >>>>
                    > >>>> Sid
                    > >>>>
                    > >>
                    > >> --
                    > >> Michael Haggerty
                    > >> Internet Applications Developer
                    > >> SiteVision, Inc.
                    > >> <e>mike@...</e>
                    > >> <p>540.343.8322 x116</p>
                    > >>
                    > >
                    > > --
                    > > Michael Haggerty
                    > > Internet Applications Developer
                    > > SiteVision, Inc.
                    > > <e>mike@...</e>
                    > > <p>540.343.8322 x116</p>
                    > >
                    > >
                    >
                    > --
                    > Michael Haggerty
                    > Internet Applications Developer
                    > SiteVision, Inc.
                    > <e>mike@...</e>
                    > <p>540.343.8322 x116</p>
                    >
                  • Mike Haggerty
                    Excellent idea, Mike! Thanks! ... -- Michael Haggerty Internet Applications Developer SiteVision, Inc. mike@sitevision.com 540.343.8322 x116
                    Message 9 of 13 , May 2 10:22 AM
                    • 0 Attachment
                      Excellent idea, Mike!

                      Thanks!

                      Mike wrote:

                      This is what I'd do:

                      <circuit access="public" xmlns:remember= "remember/ ">

                      <fuseaction name="list" remember:attributes ="CategoryID, SortOrder" >
                      ...
                      </fuseaction>

                      </circuit>

                      Then make a preFuseaction plugin:

                      <cfif not StructKeyExists( session,' rememberedAttrib utes')>
                      <cfset session.rememberedA ttributes = StructNew()>
                      </cfif>
                      <cfset theAttrs =
                      myFusebox.getCurren tFuseaction( ).getCustomAttri butes('remember' )>
                      <cfif StructKeyExists( theAttrs, 'attributes' )>
                      <cfloop index="theVar" list="#theAttrs[ 'attributes' ]#">
                      <cfif StructKeyExists( attributes, theVar)>
                      <cfset session.rememberedA ttributes[ theVar] = attributes[theVar] >
                      <cfelseif StructKeyExists( session.remember edAttributes, theVar)>
                      <cfset attributes[theVar] = session.rememberedA ttributes[ theVar]>
                      </cfif>
                      </cfloop>
                      </cfif>

                      I'm doing something similar right now in a storefront application I'm
                      writing in PHPFB5 and it works great. The first time a user accesses a
                      fuseaction they get the default view because neither var is set. If
                      they filter or sort the list they have to submit a form or click on a
                      link and the attributes scope is set, which populates the session var.
                      The next time the user access the fuseaction the session vars are set,
                      which populates the attributes vars.

                      HTH

                      Mike
                      www.fusebuilder. net

                      --- In fusebox5@yahoogroup s.com, Mike Haggerty <mike@...> wrote:
                      >
                      > Great idea.
                      >
                      > Thanks!
                      >
                      > Seth Johnson wrote:
                      > >
                      > >
                      > > Sorry, I should have looked more closely at your solution. In my
                      apps
                      > > I set a session.user struct and then append whatever session vars I
                      > > want that user to have access to. Then when they log out I kill
                      their
                      > > session struct. Otherwise you would have to loop through all of the
                      > > fa sessions that may have been created to destroy them.
                      > >
                      > >
                      > > ----- Original Message -----
                      > > *From:* Mike Haggerty <mailto:mike@ ...>
                      > > *To:* fusebox5@yahoogroup s.com <mailto:fusebox5@yahoogroup s.com>
                      > > *Sent:* Friday, May 02, 2008 12:21 PM
                      > > *Subject:* Re: [fusebox5] advice on per fuseaction session scope
                      > >
                      > > Myself is just an intermediary variable to hold session data. I
                      > > load it with data from the session struct in the global
                      > > prefuseaction, and pop it back into the session struct in the
                      > > global postfuseaction. It's just a cleaner way of having to
                      > > reference
                      > > session['#applicati on.myfusebox( ).getCurrentFuse action()# '] (or
                      > > whatever function calls will get me the current FA) in the
                      > > fuseaction. That code would get real ugly real quick.
                      > >
                      > > I was doing something along the lines of session.myself. sort, but
                      > > then if I used session.myself. sort in the foo list page, and used
                      > > the session.myself. sort variable in the bar list page, when I go
                      > > back to the foo list page it would not have the same state. So I
                      > > started thinking about using session.fooState. sort in the foo
                      > > fuseaction and session.barState. sort in the bar fuseaction, but
                      > > then thought....why not just make a site wide solution so that
                      > > every fuseaction has their own session struct available.
                      > >
                      > > Hopefully that makes sense.
                      > >
                      > > Mike
                      > >
                      > > Seth Johnson wrote:
                      > >
                      > >>
                      > >> How about shoving those values in a session struct or a user's
                      > >> cookie?
                      > >>
                      > >> I don't think myself will persist across a user's session unless
                      > >> you prepend it like so: session.myself. sort or cookie.sort
                      > >>
                      > >> Seth
                      > >>
                      > >>
                      > >>
                      > >> ----- Original Message -----
                      > >> *From:* Mike Haggerty <mailto:mike@ ...>
                      > >> *To:* fusebox5@yahoogroup s.com
                      <mailto:fusebox5@yahoogroup s.com>
                      > >> *Sent:* Friday, May 02, 2008 11:33 AM
                      > >> *Subject:* [fusebox5] advice on per fuseaction session scope
                      > >>
                      > >> Looking for some advice:
                      > >>
                      > >> There are a number of fuseactions in apps that I develop
                      > >> where I want to retain some sense of state. For example, if
                      > >> a user is on a list page, and they filter the list, and sort
                      > >> the list, then go off and play somewhere else, when they
                      > >> return to the list page, it is still in the same state as
                      > >> when they left.
                      > >>
                      > >> I have been making use of the session scope to do this, but
                      > >> I'm trying to figure out a way to make things a little
                      > >> smoother. I had this idea this morning, and wanted to bounce
                      > >> it off some more knowledgeable folk.
                      > >>
                      > >> -----
                      > >> Global Prefuseaction:
                      > >> <cfset myself = session['thisfa' ] /> <!--- use myfusebox to
                      > >> determine name of current fuseaction request --->
                      > >>
                      > >> Fuseaction:
                      > >> <cfset myself.sort = "name" />
                      > >> <cfset myself.listpage = "4" />
                      > >> <!--- state info that can change on user input --->
                      > >>
                      > >> Global Postfuseaction:
                      > >> <cfset session['thisfa' ] = myself />
                      > >> -----
                      > >>
                      > >> Is this extremely dangerous? Way too many system resources?
                      > >> Even if myself is an empty struct in most fuseactions, will
                      > >> it still be taking up way too much memory? Of course this
                      > >> all depends on resources available, and number of current
                      > >> users on system, etc., but are there any blaring red lights
                      > >> to an approach like this that I might be overlooking?
                      > >>
                      > >> Thanks for any input!
                      > >> Mike
                      > >>
                      > >>
                      > >> Ryan J. Heldt wrote:
                      > >>
                      > >>> Sid-
                      > >>>
                      > >>> One thing I usually do is create another folder (I call mine
                      > >>> /external/ but you can name it whatever you like) that has
                      > >>> it's own Application. cfc (or it cold be Application. cfm)
                      > >>> file, but has the same application name as the main
                      > >>> application so all your shared scopes are there, but it
                      > >>> doesn't extend fusebox.Application . It usually works pretty
                      > >>> well, but it's not perfect. The only real problem I have
                      > >>> with it is /remembering /to change both application names if
                      > >>> I need to rename the application for some reason.
                      > >>>
                      > >>> Thanks!
                      > >>> Ryan
                      > >>>
                      > >>> s1dw00d wrote:
                      > >>>
                      > >>>> When using Application. cfc, how can I bypass the
                      framework when
                      > >>>> requesting a .cfm page?
                      > >>>>
                      > >>>> I'm migrating an older fusebox application to 5.5 using
                      > >>>> Application. cfc. There are a few "legacy" requests that
                      > >>>> bypass the
                      > >>>> framework and they need to continue to do so for the time
                      > >>>> being. I can
                      > >>>> do this no problem using Application. cfm but I would like
                      > >>>> to use the
                      > >>>> Application. cfc if at all possible.
                      > >>>>
                      > >>>> Cheers,
                      > >>>>
                      > >>>> Sid
                      > >>>>
                      > >>
                      > >> --
                      > >> Michael Haggerty
                      > >> Internet Applications Developer
                      > >> SiteVision, Inc.
                      > >> <e>mike@...< /e>
                      > >> <p>540.343.8322 x116</p>
                      > >>
                      > >
                      > > --
                      > > Michael Haggerty
                      > > Internet Applications Developer
                      > > SiteVision, Inc.
                      > > <e>mike@...< /e>
                      > > <p>540.343.8322 x116</p>
                      > >
                      > >
                      >
                      > --
                      > Michael Haggerty
                      > Internet Applications Developer
                      > SiteVision, Inc.
                      > <e>mike@...< /e>
                      > <p>540.343.8322 x116</p>
                      >


                      -- 
                      Michael Haggerty
                      Internet Applications Developer
                      SiteVision, Inc.
                      <e>mike@...</e>
                      <p>540.343.8322 x116</p>
                    • Sean Corfield
                      ... No but some sort of flash scope support might be a good idea for FB56 or FB57 - I ll open a ticket. #336. ... Traditional plugins are CFML files. In the
                      Message 10 of 13 , May 2 10:33 AM
                      • 0 Attachment
                        On May 2, 2008, at 9:53 AM, Mike Haggerty wrote:
                        > So there's no view state akin to this built into fb55 that I am
                        > overlooking?

                        No but some sort of "flash scope" support might be a good idea for
                        FB56 or FB57 - I'll open a ticket. #336.

                        > If not, would this be something I could incorporate into a plugin so
                        > others could use it? I guess there are the preFuseaction and
                        > postFuseaction plugin phases. Can plugins be written as CFCs, or do
                        > they have to be vanilla cfm files. I guess I could always call a
                        > cfc function from the template cfm file.

                        Traditional plugins are CFML files. In the no-XML approach, you can
                        just use the Application.cfc event handlers to call fuseactions using
                        myFusebox.do(action="what.ever").

                        Sean A Corfield -- (904) 302-SEAN
                        An Architect's View -- http://corfield.org/

                        "If you're not annoying somebody, you're not really alive."
                        -- Margaret Atwood
                      Your message has been successfully submitted and would be delivered to recipients shortly.