Oh, man, Isaac...you just set my head spinning...(I think I like my simple, single programmer, 4.5.2 world...)
I think I'll just become an athiest when it comes to anything beyond 4.5.2...(it doesn't exist except on the list...it doesn't exist except on the list...) ;o) I purposefully quoted everything you just said.... aaaayyyyy! Rick > -----Original Message----- > From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] > Sent: Monday, March 06, 2006 7:27 PM > To: CF-Talk > Subject: Re: OOP, why me? > > > > I'm the sort of person who likes to understand why I'm > > doing something rather than just do it. If I download > > a UDF I analyse it and try to learn rather than just > > stick it into my app and smile because it's worked. > > With that in mind, I wonder if someone could explain > > to me in super simple, beginer speak, layman terms > > what Object Oriented Programming means in terms > > of CF and why I should use it? > > OO Programming in terms of CF means what it does in every other > language: that you have Classes ("static" methods of which can be > executed in CF using <cfinvoke component="my.component.path" > method="mymethod"> although I don't recommend this because the CF > server creates an object anyway) and Objects (which are created when > you use CreateObject() or <cfobject> to "instantiate" a CFC). There's > no magical connection between OO or OO-ness and frameworks like > Model-Glue or Mach-II -- they are no more or less OO frameworks than > any other framework except possibly with respect to the framework's > underlying guts (the part that most framework implementers never > touch) may be written as CFC's instead of procedural templates. In the > final analysis, however, this distinction of the guts of the framework > being written with Objects/OO or being written with procedural code > makes not one iota of difference to you, unless you yourself are > modifying the framework (i.e. creating a derivative framework) which > is not something most people do. > > > My very basic understanding is that you have different > > 'layers' to perform different tasks, so when someone > > visits mygroovyform.cfm the processing behind the form > > is not done on the form page itself but passed to another > > page which then passes back the results. The back end > > processing is then done using components (cfc's). > > Asside from the mention of CFCs at the end, this paragraph really > doesn't describe OO, it describes Model-View-Controller (MVC) or > something like it. I say asside from the mention of CFC's because it's > not necessary to use them (or OO/Objects) to implement an MVC > application. MVC is more like a "best practice" -- it's not a > framework because it doesn't include any specific, pre-written code, > it's merely a loose description of a good idea about how to abstract > an application so that it will be easier to expand upon that > application later. (Easier expansion is a benefit of having minimized > any interdependancies between the Model (business logic) and the View > (html, text, pdf, mobile devices, etc). The Controller is just a > concept for an intermediary between these two layers which helps in > the reduction of dependancies between them... I.e. it's sometimes > easier to eliminate dependancies between the view and the model if > they both assume that a 3rd entity (the controller) will ensure that > communication between them is accurate. This way the view can simply > assume that query-a exists, without needing to reference the model to > retrieve it, and the model can simply assume that whatever data it's > asked to provide will be appropriately used later on. Thus the > controller then becomes primarily responsible for creating the end > result by knowing that when the user requests the "orderDetail" page, > it must fetch the query from the model and include the appropriate > view. > > > I know that's a very simplified explanation but hopefully > > it's true in principle. I've written a few very simple > > CFC's more for the sake of it than because I understood > > the need. The main arguments I've heard for using this > > approach is that it's good for code re-use and promotes > > clean coding. But what I can't get my head around is why? > > I mean, code isn't necessarily unclean because it's not > > built using this approach and can't code just as easily > > be reused using a cfmodule or even a cfinclude? > > In some cases, yes, good clean code can be equally created using other > techniques like cfmodule, cfinclude or by loading function libraries. > In other cases, having "instance data" can really help to create more > legible (i.e. cleaner) syntax and/or more modular/flexible tools. > > Here's a good example: > > I had a sql-abstraction layer in my framework. Had it for a while, > originally written on CF5 (or at least written to support CF5). > Started out with a series of custom tags (cfmodule): > > <cfmodule template="#request.tapi.db.select()#" > table="mytable" return="rs"> > <cfmodule template="#request.tapi.db.filter()#" > column="x" content="#attributes.x#" /> > <cfmodule template="#request.tapi.db.filter()#" > column="y" content="#attributes.y#" /> > </cfmodule> > > Now this block of code would replace this query: > > <cfquery name="rs" datasource="primary" username="..." password="..."> > select * from mytable > where x = <cfqueryparam value="#attributes.x#" > cfsqltype="cf_sql_integer"> > and y = <cfqueryparam value="#attributes.y#" > cfsqltype="cf_sql_integer"> > </cfquery> > > Sorry for the line-wrap... anyway it's fairly obvious that there's no > keystroke savings here, and in all honesty, the cfmodule tags make it > a bit more complicated (harder to read), but I was willing to put up > with that because where SQL is inconsistent across databases, these > tags were consistent. Later I created some MX only functions to wrap > around these tags and they looked like this: > > <cfset rs = request.tapi.sql.select("mytable","*","", > request.tapi.sql.filter("x",attributes.x, > request.tapi.sql.filter("y",attributes.y,"","="),"="))> > > And while this syntax saved me some keystrokes it wasn't any more > legible. In fact it might have even been harder to read, since now you > had to nest your filters in this quirky way (and filter and join > statements had to be intermingled, and they were intermingled with the > other arguments of the select function, etc.) > > Finally when I decided to stop supporting CF5 I reinvented the SQL > abstraction with objects. The addition of instance data makes the > syntax _MUCH_ more legible and therefore much more maintainable: > > <cfset statement = datasource.getStatement("select")> > <cfset statement.filter("x",attributes.x).filter("y",attributes.y)> > <cfset rs = statement.execute()> > > Plus, this syntax does indeed make the SQL abstraction API more > flexible. A couple of exmaples: I'm now able to reference > statement.getSyntax() to return a string representation of the query > without any duplicated code. Statements can have listeners which are > notified when the statement is executed. In the case of select > statements, these listeners can act as filters on the returned query, > which as a result allows me to use a factory object to return a query > that can be sorted on data which is _not_ stored in the database. > > <cfset search = request.tap.memberFactory.getSearchStatement()> > <cfset rsMember = search.sort("language").execute()> > > Now, the names of languages is not stored in the database -- why? > Because the names of languages vary -- French when written in French > is Francais, German is Deutsch (yeah, I know, I'm butchering them, but > you get the idea). So the names of languages are provided by Java > instead of from the database. This means the database can't perform > any sorting on the language column. But ColdFusion can! Now, within > the page containing the code above that fetches the searchStatement > from my factory it isn't necessary to know that the language names > come from Java or that they won't be sorted by the databse -- it's > only necessary to know that when you search.sort("language").execute() > that the query result will be sorted by the content of that column > just like it would for any other column. This eliminates any need on > my part to provide extra sorting features which would be applied in > the page, since I know the factory will provide this feature > automatically. If I were still using custom tags or functions I would > need to either write an extra sorting routine in the page, or I would > need to write a separate wrapper tag / function for searching the > member database. You might say that getSearchStatement() is a wrapper > -- in a way it is, but it's much more flexible than wrappers written > with cfmodule or functions (without instance data), since instead of > wrapping the run-time feature (fetching the query) it only wraps the > creation of an instance of a predefined class (a select object) and > sets its parameters prior to execution. > > > I've also heard it's good in a multi-developer > > environment, but I'm only me so perhaps there > > isn't a practical reason for me to learn it at all? > > See above. :) I'm not saying you _will_ find a use for it, but once > you have a deeper understanding of the fundamentals of OO/CFCs and > "instance data" there's a good chance you might start to see new doors > opened. I'm a strong believer in the "right tool for the job" > philosophy. > > > I've read a lot on the subject and I'd like to read more > > but it's difficult to enthuse myself without understanding > > what the real end benefit is. > > > <scratches_head>Model glue, mach ii, fusebox, etc. I'm > > sure there's a bloody good reason for 'em but what > > is it?</scratches_head> > > The reasons for these is very different from the reasons for OO > actually... As I said, they're not really related. Mach-II and > Model-Glue are referred to as "OO Frameworks" more because people have > come to expect the term "OO" to be used to describe anything of value, > whether it's related to OO or not. Mach-II (and possibly Model-Glue, > I'm not sure) attempt to force the users to use CFCs for business > logic. I don't personally find this to be especially helpful, not > because I feel CFCs are a bad choice for model components / business > logic, but because it's not more than organizing those components (via > XML config) and in theory preventing bonehead noobs from making the > "mistake" of not using CFCs for a particular task. Personally I find > it much more valuable to focus on increasing the productivity of > people who know what their doing (rather than focusing on trying to > protect the code from inexperienced people) and I don't need XML to > organize my CFCs. > > I use CFCs a lot actually, I just don't like using XML to configure my > applications, and generally find that even if I did want to use XML > for configuration, the syntax for doing so with Fusebox, Mach-II and > Model-Glue are all more verbose than I prefer. I'd much rather the > framework make some basic assumptions (default values) the same way > that the ColdFusion server saves me headaches by providing common > default values with its tags. If the ColdFusion server were written > the way that these frameworks have been written, there would probably > not be a port default in the cfpop, cfmail, cfhttp or cfftp tags, and > they'd describe it as a "feature" that makes the application easier to > understand. :P > > I won't say that the onTap framework is the easiest thing in the world > to understand. It certainly reduces the amount of code I write (by > orders of magnitude actually). But then I also don't market it as an > "OO Framework" -- I market it as being OO agnostic (with gads and gads > of code-reuse and general "make life easier" tools in its various > API's). Use OO techniques if you want, skip them if you don't. Though > some of its most impressive features/API's happen to be OO driven > (SQL-Abstraction and the RuleManager facade, both of which I'll be > speaking about at the cf.Objective conference this weekend). > > > I'm not sure about books -- I'm sure others will recommend several. > And I'm sure the phrase "gang of four" will be bandied about. Whether > that's a good thing or not I couldn't say. :) May not need anything > that serious to start with... Wikipedia's got some good information > about tech terms like MVC. > > > s. isaac dealey 434.293.6201 > new epoch : isn't it time for a change? > > add features without fixtures with > the onTap open source framework > > http://www.fusiontap.com > http://coldfusion.sys-con.com/author/4806Dealey.htm > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:234355 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
