Skip navigation
Currently Being Moderated

I need my services available from...well... everywhere

Jan 21, 2014 9:35 AM

So I have these Service Objects that are instantiated during onApplicationStart().  During the onRequestStart(), I make a pointer in the variables scope to each, so they can just be called by their name (cause 'UserService') is the same as ('variables.UserService') and the latter takes less to type. GO TEAM CODE PRETTY-FICATION!

 

Anyways, during the processing of the Request, I'm finding I have to pass (as a reference) the entire variables scope to all my functions, just in case they have need of a Service.  Heck, I have a Config object that holds the application's configuration settings, so if a method needs to know the path to the controller's folder, it needs to be able to get to the variables scope where I stored my Objects.

 

But with all this object passing, I feel I'm not doing this in the most optimal way.

 

From the application.cfc point of view, the variables scope has those objects in it.  But after code in the application cfc does some includes of files which might include other files, those lower-level files don't seem to have access to that upper-level variables scope (espeically when they are called from the context of other services and methods which have their own respective variables scope)

 

So is there a simpler way of doing this, or is this what I am relegated to, since I am choosing to take an OOP design approach rather than procedural?

 
Replies
  • Currently Being Moderated
    Jan 21, 2014 9:48 AM   in reply to Aegis Kleais

    An alternative to the variables scope might be to use the request scope.  I think this is the pattern frameworks like ColdBox and FW/1 use (I could be wrong about that).  I know that they both make use of a main 'RC' variable that is passed into functions, and the RC variable contains all of the other variables needed for any part of the request process (like within service function calls).  You might look at the FW/1 docs to see how that works.

     

    As for where to store objects, it sounds like you might be needing to use a Dependency Injection system (like DI/1, ColdSpring, or WireBox).  Then you don't have to worry at all about where objects are stored (other than in the configuration file for ColdSpring or the "Convention over Configuration" approach of DI/1, or "annotations and conventions" approach of WireBox).

     

    Since I'm also a neophyte with OOP, I'm sure I've misstated some of the above, and hopefully someone with more experience will chime in and set things straight.

     

    HTH,

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 21, 2014 10:44 AM   in reply to Aegis Kleais

    I wasn't suggesting putting your objects into RC, just any variable values that the service objects may need to do their jobs.  Frameworks typically do what you are doing - combine the URL and Form scopes into RC (I'm not sure about CGI though) automatically.  Then you add in any other variables that may need to be passed into service objects (including, I think, the return values from previous service objects).

     

    If you truly do DI, you don't have to have to build the objects in order and pass them into one another, or create the objects and store them in the variables or request scope.  The DI framework does it for you.  The details of how you "wire up" the dependencies vary between the DI frameworks, but essentially you code your objects to know only that they depend on another object (whether through an XML config file, an annotation on the component/property definition, or just a defining a property that is an object).  The DI framework then goes out and creates the dependency objects for you (or if the dependency is a singleton object, it creates and caches the singleton somewhere and passes it in wherever it is needed).

     

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 21, 2014 12:51 PM   in reply to Aegis Kleais

    I'm still wrapping my head around the concepts, but I think the difference between views and layouts is that layouts are sort of like document templates that are common to the entire application (or to a subsystem) like headers and footers and site-wide stylesheets and javascript files and the like, while views are specific reusable pieces of display code (like outputting a single table or other HTML fragment that could appear on multiple pages within the application, or the even entire page minus the header/footer).  A controller can "build" your page by assembling multiple views together.

     

    -Carl V.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 22, 2014 3:19 AM   in reply to Aegis Kleais

    Aegis Kleais wrote:

     

    I need my services available from...well... everywhere

    Then store them in the application scope. Unless I am missing something.

     
    |
    Mark as:
  • Currently Being Moderated
    Jan 23, 2014 3:36 AM   in reply to Aegis Kleais

    Thanks, Aegis! You paint the picture clearly.

     

    I share your preference for OO and 'information hiding'. Like you, I have found that combining ColdFusion's native rules of thumb with those of OO can be complex. However, I have often solved difficult design problems by looking instead into the converse of a rule.

     

    Take your own design, for example:

    some of the objects I'm storing in the application.cfc's variables scope

     

    According to this, the variables are privately owned by the Application.cfc component. Therefore, by your OO reasoning, which is quite correct, any template or component that requires such a variable must obtain it via a function call. That would imply instantiating Application.cfc.

     

    However, that would break one of the fundamental rules of ColdFusion. Generally, Application.cfc is not designed to be instantiated.

     

    It is at a point like this that I would reevaluate the use of variables scope in Application.cfc. In fact, one obvious solution is to store variables meant for template requests in the request scope within onRequestStart. As they say, what's in a name?

     

    Then again, Carl suggested this, too. You actually thought of it earlier yourself! So, I'll stop trying to sell this fridge to an Eskimo.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points