I'm assuming that you've stumbled across CFRhino and want to know a bit more about it, without downloading it, installing it and then having to read a bunch of documentation. So let me try and explain; CFRhino is a ColdFusion framework written, primarily, with maintenance in mind. I was getting sick and tired of changing all the pages on my site every time I decided to change a menu or link or something. So I decided to create a templating framework, that used a small number of files to control the way that a page was put together, an XML configuration file that defined what pieces of information went where for each page and a collection of page pieces or pagelets.
It was designed with the MVC (Model View Control) pattern in mind, although I'm not going to call it an MVC framework as I don't think it goes that far. It does help you separate the display logic (view) from the data logic (model) and provides a mechanism of handling requests and posts (control). However, CFRhino does not make you use MVC nor does it force you to program in strict OO paradigms.
As CFRhino grew, so did what I wanted to do with it (and you have to understand that much of what CFRhino currently does it down to my requirements). Behind the scenes CFRhino has an integrated event framework, that allows you to register handlers (singleton CFC's) for events when the framework starts up and those events can be called at any time during a page request. CFRhino also has a request scoped data cache that stores CFC's during the life of a request. This helps reduce object instantiation costs when rendering a page of multiple pagelets.
The construction of a page is parsed out of the pages.xml file and used by page.cfc when a request for particular page is made. The particular key from the parsed struct is used to pass the correct data to the space.cfc component. This is used to fetch the correct pagelet into the appropriate space.
The XML doesn't know whether the requested pagelet is from the applications own pagelet store, the pagelet store of an application local extension or a central core extension. This information is instead, calculated from the naming of the pagelet being requested.
The first part on the dot separated string is checked for a match, first with the applications name, then against the event.cfc for a recorded type (appextension or coreextension).
Controllers for the main application are held in a struct within the page.cfc. Other controllers are handled by the respective extension. As such, if 'page' cannot identify a request from it's local controller list it issues a getPageletUndefined event and sees if any other loaded extension can handle it.
Data is fetched through CFRhino via the data object, that is held in the request scope. There are two ways to define data in CFRhino: the first is as a combintation of data provider (CFC) method name and argument mappings, the second is using a direct call to a CFC within the framework. Both have their advantages, the first method allows CFRhino to determine whether all the arguments are valid and present before instantiating the data object the other allows the display pagelets to grab hold of a complete CFC and use it any way they wish.
You obtain an instantiated CFC from CFRhino using the getObject() method on the framework's data object.
request.data.getObject("mydata"); // this assumes that the data object is in the main application path.
To keep CFC's independent of the CFRhino framework, a pattern of passing a context to each instantiated CFC is encouraged. The context struct can be obtained from rhino using the getContext() method, however, if you choose to utilise this pattern you can also create your own struct outside of the framework and pass that it. Generally, the context is passed in as an attribute of the init() method (generally regarded as the constructor).
<cfset myObj = request.data.getObject("myObj").init(request.rhino.getContext())>