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

Model: to FB or not to FB

Expand Messages
  • houston_blue_texas
    [No-XML, MVC.] I know FB best-practice is to allow FB s application.cfc to control the model...but...a colleague, who s an RoR/PHP person learning CF & FB,
    Message 1 of 9 , May 13, 2009
    • 0 Attachment
      [No-XML, MVC.]

      I know FB best-practice is to allow FB's application.cfc to control the model...but...a colleague, who's an RoR/PHP person learning CF & FB, asked, "Why?" I said, "So that the model can 'see' FB's application, session, myFusebox, event, etc scopes." And he (correctly) pointed out that those could be passed, as needed, as arguments into non-FB CFC's. So I'm putting it to the community: what're the top 1-3 reasons why it's FB best-practice to allow FB's application.cfc to control the model?
    • Barney Boisvert
      I think that mechanism gets a lot of false weight for three main reasons: 1) it keeps everything in FB with no reliance on other technologies 2) it s easier to
      Message 2 of 9 , May 13, 2009
      • 0 Attachment
        I think that mechanism gets a lot of false weight for three main reasons:

        1) it keeps everything in FB with no reliance on other technologies
        2) it's easier to build demos that way
        3) everyone who knows it's a generally silly way to do it just does it
        the right way without thinking

        My applications are almost invariably centered around a ColdSpring
        instance managed in Application.cfc. The beans exposed via ColdSpring
        provide the API to the app's business logic. Then I build one or more
        presentation layers that leverage those CS-managed beans to get their
        job (interact with the user) done.

        cheers,
        barneyb

        On Wed, May 13, 2009 at 3:17 PM, houston_blue_texas
        <bliss.john@...> wrote:
        > [No-XML, MVC.]
        >
        > I know FB best-practice is to allow FB's application.cfc to control the model...but...a colleague, who's an RoR/PHP person learning CF & FB, asked, "Why?"  I said, "So that the model can 'see' FB's application, session, myFusebox, event, etc scopes."  And he (correctly) pointed out that those could be passed, as needed, as arguments into non-FB CFC's.  So I'm putting it to the community: what're the top 1-3 reasons why it's FB best-practice to allow FB's application.cfc to control the model?
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >



        --
        Barney Boisvert
        bboisvert@...
        http://www.barneyb.com/
      • John M Bliss
        So if we re *not* using CS, you recommend sticking to FB best-practice -or- running your model CFC s outside of FB? And why? ... -- John Bliss IT Professional
        Message 3 of 9 , May 14, 2009
        • 0 Attachment
          So if we're not using CS, you recommend sticking to FB best-practice -or- running your model CFC's outside of FB?  And why?

          On Wed, May 13, 2009 at 11:01 PM, Barney Boisvert <bboisvert@...> wrote:


          I think that mechanism gets a lot of false weight for three main reasons:

          1) it keeps everything in FB with no reliance on other technologies
          2) it's easier to build demos that way
          3) everyone who knows it's a generally silly way to do it just does it
          the right way without thinking

          My applications are almost invariably centered around a ColdSpring
          instance managed in Application.cfc. The beans exposed via ColdSpring
          provide the API to the app's business logic. Then I build one or more
          presentation layers that leverage those CS-managed beans to get their
          job (interact with the user) done.

          cheers,
          barneyb



          On Wed, May 13, 2009 at 3:17 PM, houston_blue_texas
          <bliss.john@...> wrote:
          > [No-XML, MVC.]
          >
          > I know FB best-practice is to allow FB's application.cfc to control the model...but...a colleague, who's an RoR/PHP person learning CF & FB, asked, "Why?"  I said, "So that the model can 'see' FB's application, session, myFusebox, event, etc scopes."  And he (correctly) pointed out that those could be passed, as needed, as arguments into non-FB CFC's.  So I'm putting it to the community: what're the top 1-3 reasons why it's FB best-practice to allow FB's application.cfc to control the model?
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
          >

          --
          Barney Boisvert
          bboisvert@...
          http://www.barneyb.com/



          --
          John Bliss
          IT Professional
          LinkedIn: http://www.linkedin.com/in/jbliss
        • Sean Corfield
          ... The model should be independent of FB. The model should not - except in the case of certain facade scenarios - reference any of the global scopes, nor any
          Message 4 of 9 , May 14, 2009
          • 0 Attachment
            On Thu, May 14, 2009 at 7:32 AM, John M Bliss <bliss.john@...> wrote:
            > So if we're not using CS, you recommend sticking to FB best-practice -or-
            > running your model CFC's outside of FB?  And why?

            The model should be independent of FB.

            The model should not - except in the case of certain facade scenarios
            - reference any of the global scopes, nor any of the FB types. Passing
            myFusebox or the event object to a model CFC method should be
            considered a bad code smell.

            I tend to put my model - CS-managed or not - outside FB and have the
            'scope bleed' (references to application scope) only in my FB
            controllers.

            I just opened a ticket to add generic bean factory support to FB, with
            a code patch that I've been using to great success on a project. In
            Application.cfc, I instantiate ColdSpring and store it in Fusebox
            (using a new setBeanFactory() method). In FB code I use
            myFusebox.getBean('foo') to retrieve items. My model knows nada about
            FB.
            --
            Sean A Corfield -- (904) 302-SEAN
            Railo Technologies US -- http://getrailo.com/
            An Architect's View -- http://corfield.org/

            "If you're not annoying somebody, you're not really alive."
            -- Margaret Atwood
          • John M Bliss
            Interesting. Fusebox 5 & FLiP, How To Drive Fusebox 5.5, and (I think) all sample apps at http://fusebox.org/go/fusebox-downloads/sample-applications have
            Message 5 of 9 , May 14, 2009
            • 0 Attachment
              Interesting.  "Fusebox 5 & FLiP," "How To Drive Fusebox 5.5," and (I think) all sample apps at http://fusebox.org/go/fusebox-downloads/sample-applications have the model running "under" FB.

              They're wrong or something changed?


              On Thu, May 14, 2009 at 7:54 AM, Sean Corfield <seancorfield@...> wrote:


              On Thu, May 14, 2009 at 7:32 AM, John M Bliss <bliss.john@...> wrote:
              > So if we're not using CS, you recommend sticking to FB best-practice -or-
              > running your model CFC's outside of FB?  And why?

              The model should be independent of FB.

              The model should not - except in the case of certain facade scenarios
              - reference any of the global scopes, nor any of the FB types. Passing
              myFusebox or the event object to a model CFC method should be
              considered a bad code smell.

              I tend to put my model - CS-managed or not - outside FB and have the
              'scope bleed' (references to application scope) only in my FB
              controllers.

              I just opened a ticket to add generic bean factory support to FB, with
              a code patch that I've been using to great success on a project. In
              Application.cfc, I instantiate ColdSpring and store it in Fusebox
              (using a new setBeanFactory() method). In FB code I use
              myFusebox.getBean('foo') to retrieve items. My model knows nada about
              FB.
              --
              Sean A Corfield -- (904) 302-SEAN
              Railo Technologies US -- http://getrailo.com/
              An Architect's View -- http://corfield.org/

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



              --
              John Bliss
              IT Professional
              LinkedIn: http://www.linkedin.com/in/jbliss
            • Sean Corfield
              ... Exactly Barney s point: easiest way to build demo apps - but not the right way to build real production apps. The books don t show complex enough models to
              Message 6 of 9 , May 14, 2009
              • 0 Attachment
                On Thu, May 14, 2009 at 7:59 AM, John M Bliss <bliss.john@...> wrote:
                > Interesting.  "Fusebox 5 & FLiP," "How To Drive Fusebox 5.5," and (I think)
                > all sample apps at
                > http://fusebox.org/go/fusebox-downloads/sample-applications have the model
                > running "under" FB.
                >
                > They're wrong or something changed?

                Exactly Barney's point: easiest way to build demo apps - but not the
                right way to build real production apps.

                The books don't show complex enough models to "bother" doing it right...
                --
                Sean A Corfield -- (904) 302-SEAN
                Railo Technologies US -- http://getrailo.com/
                An Architect's View -- http://corfield.org/

                "If you're not annoying somebody, you're not really alive."
                -- Margaret Atwood
              • John M Bliss
                I see. So how do we, as a community, teach new FB people the right way to do it? ... -- John Bliss IT Professional LinkedIn: http://www.linkedin.com/in/jbliss
                Message 7 of 9 , May 14, 2009
                • 0 Attachment
                  I see.  So how do we, as a community, teach new FB people the right way to do it?

                  On Thu, May 14, 2009 at 8:44 AM, Sean Corfield <seancorfield@...> wrote:


                  On Thu, May 14, 2009 at 7:59 AM, John M Bliss <bliss.john@...> wrote:
                  > Interesting.  "Fusebox 5 & FLiP," "How To Drive Fusebox 5.5," and (I think)
                  > all sample apps at
                  > http://fusebox.org/go/fusebox-downloads/sample-applications have the model
                  > running "under" FB.
                  >
                  > They're wrong or something changed?

                  Exactly Barney's point: easiest way to build demo apps - but not the
                  right way to build real production apps.

                  The books don't show complex enough models to "bother" doing it right...

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

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



                  --
                  John Bliss
                  IT Professional
                  LinkedIn: http://www.linkedin.com/in/jbliss
                • Josh Carrico
                  Sean, I instantiate ColdSpring and store it in Fusebox ... What does the cost of this look like on startup? Thanks. JOSH
                  Message 8 of 9 , May 14, 2009
                  • 0 Attachment
                    Sean,

                    I instantiate ColdSpring and store it in Fusebox

                    What does the cost of this look like on startup?

                    Thanks.
                    JOSH

                    On Thu, May 14, 2009 at 8:54 AM, Sean Corfield <seancorfield@...> wrote:


                    On Thu, May 14, 2009 at 7:32 AM, John M Bliss <bliss.john@...> wrote:
                    > So if we're not using CS, you recommend sticking to FB best-practice -or-
                    > running your model CFC's outside of FB?  And why?

                    The model should be independent of FB.

                    The model should not - except in the case of certain facade scenarios
                    - reference any of the global scopes, nor any of the FB types. Passing
                    myFusebox or the event object to a model CFC method should be
                    considered a bad code smell.

                    I tend to put my model - CS-managed or not - outside FB and have the
                    'scope bleed' (references to application scope) only in my FB
                    controllers.

                    I just opened a ticket to add generic bean factory support to FB, with
                    a code patch that I've been using to great success on a project. In
                    Application.cfc, I instantiate ColdSpring and store it in Fusebox
                    (using a new setBeanFactory() method). In FB code I use
                    myFusebox.getBean('foo') to retrieve items. My model knows nada about
                    FB.
                    --
                    Sean A Corfield -- (904) 302-SEAN
                    Railo Technologies US -- http://getrailo.com/
                    An Architect's View -- http://corfield.org/

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

                  • Sean Corfield
                    ... The default is lazy-init=true so it has negligible impact. Even with lazy-init=false you won t notice it unless you have hundreds of interdependent
                    Message 9 of 9 , May 14, 2009
                    • 0 Attachment
                      On Thu, May 14, 2009 at 8:55 AM, Josh Carrico <sigepjedi@...> wrote:
                      >> I instantiate ColdSpring and store it in Fusebox
                      >
                      > What does the cost of this look like on startup?

                      The default is lazy-init=true so it has negligible impact. Even with
                      lazy-init=false you won't notice it unless you have hundreds of
                      interdependent singletons.

                      Assuming you have Report Execution Times turned OFF (which you'd need
                      off for FB5 anyway).

                      If you're on the Java 6 that ships with CF8, you may run into the JVM
                      bug that causes class loading performance issues (Google for
                      ColdFusion 8 Java 6 to see solutions).
                      --
                      Sean A Corfield -- (904) 302-SEAN
                      Railo Technologies US -- http://getrailo.com/
                      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.