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

Re: [fusebox5] Re: problems in FB5.5

Expand Messages
  • 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 1 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 2 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.