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

Re: problems in FB5.5

Expand Messages
  • xyxoxy
    ... That makes a lot of sense explained that way. Thanks! Am I correct that this behavior is new in FB5.5 and/or only happens when FB is launched from app.cfc?
    Message 1 of 7 , Mar 31, 2009
    • 0 Attachment
      --- In fusebox5@yahoogroups.com, Sean Corfield <seancorfield@...> wrote:
      > Since Fusebox controls all requests, it will intercept anything that
      > doesn't go through index.cfm and force you back to the Fusebox app.
      > That's why you get a loop: your default fuseaction is triggering an
      > exception and your error handling is triggering a redirect to a
      > non-index.cfm file and Fusebox is redirecting you back to your default
      > fuseaction!
      > --

      That makes a lot of sense explained that way. Thanks!

      Am I correct that this behavior is new in FB5.5 and/or only happens when FB is launched from app.cfc? My (limited) experience with FB5.1 (no app.cfc) makes me think that FB only takes control when told to via "...index.cfm?method=xxx". I've used the <relocate> verb in my circuit.xml files but if I had reason to use a non-FB <cflocation> tag in a FB5.1 app I don't think it would cause a loop. In fact I don't think FB would even be involved after that point without app.cfc sending you there. (yes/no?)

      FYI - I did quickly try the hack suggested by Aliaspooryorik and at first glance it seemed to solve my problem. I had to switch gears to a "real" project today so I could only play for a few minutes.

      Again I really appreciate your time.
    • Sean Corfield
      ... In general, FB skeletons have always contained code to trap non-index.cfm requests and redirect them back to index.cfm. That s usually in Application.cfm,
      Message 2 of 7 , Apr 1, 2009
      • 0 Attachment
        On Tue, Mar 31, 2009 at 9:06 PM, xyxoxy <xyxoxy@...> wrote:
        > Am I correct that this behavior is new in FB5.5 and/or only happens when FB
        > is launched from app.cfc? My (limited) experience with FB5.1 (no app.cfc)
        > makes me think that FB only takes control when told to via
        > "...index.cfm?method=xxx".

        In general, FB skeletons have always contained code to trap
        non-index.cfm requests and redirect them back to index.cfm. That's
        usually in Application.cfm, e.g.,

        <cfif right(cgi.script_name, len("index.cfm")) neq "index.cfm" and
        right(cgi.script_name, 3) neq "cfc">
        <cflocation url="index.cfm" addtoken="no" />
        </cfif>

        The fusebox5/Application.cfc approach is a little different because it
        controls onRequest() and therefore it automatically intercepts every
        request and routes it through the framework. Same principle, different
        implementation.

        So I misspoke when I said that it redirected you back to index.cfm -
        it doesn't, but it doesn't allow the request through either. Even
        index.cfm is ignored (by design) since, for several FB releases,
        index.cfm has essentially been just a placeholder to include the
        framework anyway. If you look in the FB5 skeleton index.cfm, it says:

        <!---
        sample index.cfm if you use Application.cfm
        this should be empty if you use Application.cfc
        --->

        It's deliberately setup to work with both Application.cfm and
        Application.cfc (which is why it isn't actually empty).

        So, back to your use case...

        If you actually want people to be able to request non-index.cfm files,
        you need to add logic for that in your Application.cfc in an
        onRequest() method, something like this:

        <cffunction name="onRequest">
        <cfargument name="targetPage">
        <cfif right(arguments.targetPage,9) is not "index.cfm">
        <cfinclude template="#arguments.targetPage#>
        <cfelse>
        <cfset super.onRequest(arguments.targetPage)>
        </cfif>
        </cffunction>

        This will let Fusebox handle index.cfm requests and simply attempt to
        include (run) any other requested pages.

        Untested, let me know if/how it works.
        --
        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
      • Adam Haskell
        You will want that in OnRequestStart the FB magic happens in OnRequestStart, OnRequest simply does the include, most of the FB startup and path checking
        Message 3 of 7 , Apr 2, 2009
        • 0 Attachment
          You will want that in OnRequestStart the FB magic happens in OnRequestStart, OnRequest simply does the include, most of the FB startup and path checking happens in OnRequestStart. I think I have a ticket in the new Jira system that is half done (Thinking I might get to finish that this weekend) about a new Fusebox parameter with an array of file paths to allow pass through.

          Adam


          On Wed, Apr 1, 2009 at 4:13 PM, Sean Corfield <seancorfield@...> wrote:

          On Tue, Mar 31, 2009 at 9:06 PM, xyxoxy <xyxoxy@...> wrote:
          > Am I correct that this behavior is new in FB5.5 and/or only happens when FB
          > is launched from app.cfc? My (limited) experience with FB5.1 (no app.cfc)
          > makes me think that FB only takes control when told to via
          > "...index.cfm?method=xxx".

          In general, FB skeletons have always contained code to trap
          non-index.cfm requests and redirect them back to index.cfm. That's
          usually in Application.cfm, e.g.,

          <cfif right(cgi.script_name, len("index.cfm")) neq "index.cfm" and
          right(cgi.script_name, 3) neq "cfc">
          <cflocation url="index.cfm" addtoken="no" />
          </cfif>

          The fusebox5/Application.cfc approach is a little different because it
          controls onRequest() and therefore it automatically intercepts every
          request and routes it through the framework. Same principle, different
          implementation.

          So I misspoke when I said that it redirected you back to index.cfm -
          it doesn't, but it doesn't allow the request through either. Even
          index.cfm is ignored (by design) since, for several FB releases,
          index.cfm has essentially been just a placeholder to include the
          framework anyway. If you look in the FB5 skeleton index.cfm, it says:

          <!---
          sample index.cfm if you use Application.cfm
          this should be empty if you use Application.cfc
          --->

          It's deliberately setup to work with both Application.cfm and
          Application.cfc (which is why it isn't actually empty).

          So, back to your use case...

          If you actually want people to be able to request non-index.cfm files,
          you need to add logic for that in your Application.cfc in an
          onRequest() method, something like this:

          <cffunction name="onRequest">
          <cfargument name="targetPage">
          <cfif right(arguments.targetPage,9) is not "index.cfm">
          <cfinclude template="#arguments.targetPage#>
          <cfelse>
          <cfset super.onRequest(arguments.targetPage)>
          </cfif>
          </cffunction>

          This will let Fusebox handle index.cfm requests and simply attempt to
          include (run) any other requested pages.

          Untested, let me know if/how it works.

          --
          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.