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

Replicating globalfuseactions>postprocess in noxml

Expand Messages
  • aliaspooryorik
    Hi, I m converting an application from Fusebox 4 to 5.5 No XML and the only real issue I ve hit is that the current application uses the globalfuseactions
    Message 1 of 5 , Sep 8, 2008
    • 0 Attachment
      Hi,
      I'm converting an application from Fusebox 4 to 5.5 No XML and the
      only real issue I've hit is that the current application uses the
      globalfuseactions > postprocess in Fusebox.xml to render the layout.

      No XML doesn't have (as far as I know) a direct replacement for this,
      I've found that you can use the onRequestEnd() method to mimic it but
      I'm pretty sure this is bad practice. I can't use the postfuseaction
      method in the circuit as fuses call other (internal) fuses.

      This is what I've got:

      <cffunction name="onRequestEnd" output="true">
      <cfargument name="targetPage"
      type="string"
      required="true" />
      <cfoutput>#myFusebox.do( 'layouts.buildPage' )#</cfoutput>

      <!--- Pass request to Fusebox. --->
      <cfset super.onRequestEnd(arguments.targetPage) />

      ...
      </cffunction>

      Anyone have a better way of doing this?

      Thanks!
    • Sean Corfield
      ... Well, I would suggest that best practice is to have a controller circuit that calls down into the model and view - in which case you could use
      Message 2 of 5 , Sep 8, 2008
      • 0 Attachment
        On Sep 8, 2008, at 6:27 AM, aliaspooryorik wrote:
        > No XML doesn't have (as far as I know) a direct replacement for this,
        > I've found that you can use the onRequestEnd() method to mimic it but
        > I'm pretty sure this is bad practice. I can't use the postfuseaction
        > method in the circuit as fuses call other (internal) fuses.

        Well, I would suggest that best practice is to have a controller
        circuit that calls down into the model and view - in which case you
        could use pre/postfuseaction on the controller (since it doesn't call
        any other controller fuseactions).

        However, the global fuseactions map directly to onRequestStart() /
        onRequestEnd() so you're OK using those too. That's why Fusebox 5.5
        allows you to 'do' fuseactions directly inside those methods.

        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
      • aliaspooryorik
        Thanks Sean :) I m currently refactoring Brian Kotek s fbbookstore from Fusebox 4.1 to 5.5 no xml so wanted to do like for like as much a possible to start
        Message 3 of 5 , Sep 9, 2008
        • 0 Attachment
          Thanks Sean :)
          I'm currently refactoring Brian Kotek's fbbookstore from Fusebox 4.1
          to 5.5 no xml so wanted to do like for like as much a possible to
          start with. I'm hoping to blog about it as an example app for Fusebox
          5.5 no xml and OO. If I get the chance I'll then switch it to use a
          seperate controller.

          - John

          --- In fusebox5@yahoogroups.com, Sean Corfield <seanc@...> wrote:
          Well, I would suggest that best practice is to have a controller
          circuit that calls down into the model and view - in which case you
          could use pre/postfuseaction on the controller (since it doesn't call
          any other controller fuseactions).

          However, the global fuseactions map directly to onRequestStart() /
          onRequestEnd() so you're OK using those too. That's why Fusebox 5.5
          allows you to 'do' fuseactions directly inside those methods.
        • Adam Haskell
          That s and interesting take on it Sean. I wonder though if putting it in each controller is really necessary all the time? I can see in some sophisticated
          Message 4 of 5 , Sep 9, 2008
          • 0 Attachment
            That's and interesting take on it Sean. I wonder though if putting it in each controller is really necessary all the time? I can see in some sophisticated sites that have a different look and feel throughout the sections this being the case. I would not say putting it in the controller is any more or less a best practice than putting it in OnRequestEnd. I think it solely depends on how much the layout fluctuates through the application. In out intranet 95% of our applications have the same layout throughout so we happily have the layout in the OnRequestEnd. YMMV.


            Adam Haskell


            On Mon, Sep 8, 2008 at 11:27 AM, Sean Corfield <seanc@...> wrote:

            On Sep 8, 2008, at 6:27 AM, aliaspooryorik wrote:
            > No XML doesn't have (as far as I know) a direct replacement for this,
            > I've found that you can use the onRequestEnd() method to mimic it but
            > I'm pretty sure this is bad practice. I can't use the postfuseaction
            > method in the circuit as fuses call other (internal) fuses.

            Well, I would suggest that best practice is to have a controller
            circuit that calls down into the model and view - in which case you
            could use pre/postfuseaction on the controller (since it doesn't call
            any other controller fuseactions).

            However, the global fuseactions map directly to onRequestStart() /
            onRequestEnd() so you're OK using those too. That's why Fusebox 5.5
            allows you to 'do' fuseactions directly inside those methods.

            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
            You get into trouble if you start running AJAX calls and your layout gets thrown on top of the result . . . that is the most compelling reason I have found for
            Message 5 of 5 , Sep 9, 2008
            • 0 Attachment

              You get into trouble if you start running AJAX calls and your layout gets thrown on top of the result . . . that is the most compelling reason I have found for keeping layout calls within the fa's as opposed to OnRequestEnd().  With that said (and with this method), I would have to concur with Sean about not having controller fa's calling other controller fa's because then you could have the template applied twice (or more).  I think it allows greater flexibility in the future if you just avoid it.


              Seth

               

              From: fusebox5@yahoogroups.com [mailto:fusebox5@yahoogroups.com] On Behalf Of Adam Haskell
              Sent: Tuesday, September 09, 2008 1:49 PM
              To: fusebox5@yahoogroups.com
              Subject: Re: [fusebox5] Replicating globalfuseactions>postprocess in noxml

               

              That's and interesting take on it Sean. I wonder though if putting it in each controller is really necessary all the time? I can see in some sophisticated sites that have a different look and feel throughout the sections this being the case. I would not say putting it in the controller is any more or less a best practice than putting it in OnRequestEnd. I think it solely depends on how much the layout fluctuates through the application. In out intranet 95% of our applications have the same layout throughout so we happily have the layout in the OnRequestEnd. YMMV.


              Adam Haskell

              On Mon, Sep 8, 2008 at 11:27 AM, Sean Corfield <seanc@...> wrote:

              On Sep 8, 2008, at 6:27 AM, aliaspooryorik wrote:

              > No XML doesn't have (as far as I know) a direct replacement for this,
              > I've found that you can use the onRequestEnd() method to mimic it but
              > I'm pretty sure this is bad practice. I can't use the postfuseaction
              > method in the circuit as fuses call other (internal) fuses.

              Well, I would suggest that best practice is to have a controller
              circuit that calls down into the model and view - in which case you
              could use pre/postfuseaction on the controller (since it doesn't call
              any other controller fuseactions).

              However, the global fuseactions map directly to onRequestStart() /
              onRequestEnd() so you're OK using those too. That's why Fusebox 5.5
              allows you to 'do' fuseactions directly inside those methods.

              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.