RE: [ACFUG Discuss] Learning a ColdFusion Framework: Update
Hey Clarke, I caught your comment here, that I was originally going to start with ColdBox to learn a ColdFusion framework. But, I quickly got lost in the complexity. To really use ColdBox, you end up needing to know Coldspring and Transfer. But, since each of those has a learning curve, it really makes things hard. I thought that odd. I'd not heard it to be the case, so I ran it by Luis (Majano, who created and leads the framework effort). He said, Coldbox doesn't require any frameworks. He really wondered how you may have come to that conclusion, and how far you had explored things before concluding it. Was it maybe some samples they showed that led you to conclude that? He said, The simple mvc apps are all conventions and the guides are also straightforward. To be clear, I'm not knocking CFWheels at all, nor your choice should you choose to stay with it. But should you want to explore things further, he noted that the google group or forums would be a welcome place to discuss it so everyone there could chime in: http://groups.google.com/group/coldbox http://ortus.svnrepository.com/coldbox But I appreciate that you may not care to bother logging in and sharing the thoughts if you've simply moved on. If you have any thought you might like me to pass back to him, I certainly could. Hope that's helpful. BTW, great to see you starting to blog. Thanks for doing that. I was a little confused when the first item in your recent posts list was what is a web application server, and it talked about cold fusion. Then I noticed it was from 2003, and that your archives lists had nothing since then, too. Man, quite a gap. Welcome back from the blogging deadzone. :-) /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Clarke Bishop Sent: Tuesday, August 11, 2009 10:07 AM To: discussion@acfug.org Subject: [ACFUG Discuss] Learning a ColdFusion Framework: Update I was originally going to start with ColdBox to learn a ColdFusion framework. But, I quickly got lost in the complexity. To really use ColdBox, you end up needing to know Coldspring and Transfer. But, since each of those has a learning curve, it really makes things hard. So, I switched to CFWheels (http://cfwheels.org/ ). Wheels is a ColdFusion framework based on Ruby on Rails. Just like Rails, the CFWheels framework use an active record approach, so there's no need for Transfer or Reactor. And, the object dependencies are also managed by the framework, so you don't need Coldspring. There's still a lot to learn because you have to learn to think the way the framework expects. And, you have to learn the conventions for how things should be named, etc. I found a great book that helped me adjust my thinking - Head First Rails. But, it's Ruby/Rails, of course. I've found that the ideas translate fairly easily to CFWheels, and I've started converting the apps in the book to CFWheels. To help me learn it more deeply, I decided to blog about the process, so if you want, take a look at: http://www.resultantsys.com/index.php/coldfusion/cfwheels-scaffolding-basics / Thanks again for all the ideas and support I got from you guys. I'll keep you posted on my progress! Clarke - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
RE: [ACFUG Discuss] Learning a ColdFusion Framework: Update
Thanks Charlie for the clarifications! I'm sure that I don't have the perspective to do a rigorous evaluation of ColdBox or any framework for that matter. I did see some samples that assumed Coldspring and Transfer. And, I don't understand how else you would manage dependencies and ORM within ColdBox. I know that technically, you don't need to use ORM/database as part of a framework, but all the apps I'm interested in would need that ability. So, if there's some built-in ORM in ColdBox, please let me know. To me, CFWheels just made more sense. It let me focus on learning MVC and it handles all the ORM dependency stuff for me. And, I got a lot out of that Head First Rails book, too. There are a lot of Rails apps to use as examples, and I'm currently trying to port some over to CFML. I'm still very impressed with ColdBox. It seems very complete, and I think it's a lot more powerful than CFWheels and maybe any of the other frameworks, too. It's just that it seemed too much for where I am on my learning curve. If I decide to move on from CFWheels, ColdBox would by my first choice alternative! Clarke p.s. I haven't been blogging much on my Resultant website, but I have been blogging on other topics! The 2003 posts were originally articles on my old website. I've been interested in Rich Internet Apps and web technology for a long time. I originally wrote that web app article for some people at BellSouth. In the old days, my development team used CF 1.5 for a prototype back in 1996, and we used jrun for a while, too! From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Charlie Arehart Sent: Monday, August 17, 2009 6:53 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] Learning a ColdFusion Framework: Update Hey Clarke, I caught your comment here, that I was originally going to start with ColdBox to learn a ColdFusion framework. But, I quickly got lost in the complexity. To really use ColdBox, you end up needing to know Coldspring and Transfer. But, since each of those has a learning curve, it really makes things hard. I thought that odd. I'd not heard it to be the case, so I ran it by Luis (Majano, who created and leads the framework effort). He said, Coldbox doesn't require any frameworks. He really wondered how you may have come to that conclusion, and how far you had explored things before concluding it. Was it maybe some samples they showed that led you to conclude that? He said, The simple mvc apps are all conventions and the guides are also straightforward. To be clear, I'm not knocking CFWheels at all, nor your choice should you choose to stay with it. But should you want to explore things further, he noted that the google group or forums would be a welcome place to discuss it so everyone there could chime in: http://groups.google.com/group/coldbox http://ortus.svnrepository.com/coldbox But I appreciate that you may not care to bother logging in and sharing the thoughts if you've simply moved on. If you have any thought you might like me to pass back to him, I certainly could. Hope that's helpful. BTW, great to see you starting to blog. Thanks for doing that. I was a little confused when the first item in your recent posts list was what is a web application server, and it talked about cold fusion. Then I noticed it was from 2003, and that your archives lists had nothing since then, too. Man, quite a gap. Welcome back from the blogging deadzone. :-) /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Clarke Bishop Sent: Tuesday, August 11, 2009 10:07 AM To: discussion@acfug.org Subject: [ACFUG Discuss] Learning a ColdFusion Framework: Update I was originally going to start with ColdBox to learn a ColdFusion framework. But, I quickly got lost in the complexity. To really use ColdBox, you end up needing to know Coldspring and Transfer. But, since each of those has a learning curve, it really makes things hard. So, I switched to CFWheels (http://cfwheels.org/ ). Wheels is a ColdFusion framework based on Ruby on Rails. Just like Rails, the CFWheels framework use an active record approach, so there's no need for Transfer or Reactor. And, the object dependencies are also managed by the framework, so you don't need Coldspring. There's still a lot to learn because you have to learn to think the way the framework expects. And, you have to learn the conventions for how things should be named, etc. I found a great book that helped me adjust my thinking - Head First Rails. But, it's Ruby/Rails, of course. I've found that the ideas translate fairly easily to CFWheels, and I've started converting the apps in the book to CFWheels. To help me learn it more deeply, I decided to blog about the process, so if you want, take a look at: http://www.resultantsys.com/index.php/coldfusion/cfwheels-scaffolding-basics / Thanks again for all the ideas and support I got from you guys. I'll keep
RE: [ACFUG Discuss] Learning a ColdFusion Framework: Update
Well, I don't use ColdBox myself, so I can't answer your question about whether CB expects one to use an ORM. Maybe someone else can chime here, or again the CB list/forum would be a great place to ask. I just wanted to clarify that one point about it not needing transfer or coldpsring to do development. I just had not heard that, in the mild exploration I've done of CB. Good to hear of your enjoyment of CFWheels. I'll look forward to what you share about that transition. /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Clarke Bishop Sent: Monday, August 17, 2009 8:15 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] Learning a ColdFusion Framework: Update Thanks Charlie for the clarifications! I'm sure that I don't have the perspective to do a rigorous evaluation of ColdBox or any framework for that matter. I did see some samples that assumed Coldspring and Transfer. And, I don't understand how else you would manage dependencies and ORM within ColdBox. I know that technically, you don't need to use ORM/database as part of a framework, but all the apps I'm interested in would need that ability. So, if there's some built-in ORM in ColdBox, please let me know. To me, CFWheels just made more sense. It let me focus on learning MVC and it handles all the ORM dependency stuff for me. And, I got a lot out of that Head First Rails book, too. There are a lot of Rails apps to use as examples, and I'm currently trying to port some over to CFML. I'm still very impressed with ColdBox. It seems very complete, and I think it's a lot more powerful than CFWheels and maybe any of the other frameworks, too. It's just that it seemed too much for where I am on my learning curve. If I decide to move on from CFWheels, ColdBox would by my first choice alternative! Clarke p.s. I haven't been blogging much on my Resultant website, but I have been blogging on other topics! The 2003 posts were originally articles on my old website. I've been interested in Rich Internet Apps and web technology for a long time. I originally wrote that web app article for some people at BellSouth. In the old days, my development team used CF 1.5 for a prototype back in 1996, and we used jrun for a while, too! - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
RE: [ACFUG Discuss] Learning a ColdFusion Framework: Update
For those of you who are interested in how I'm learning CFWheels, I've added a jump page to organize my blog posts. http://www.resultantsys.com/index.php/cfwheels Please let me know what you think! Clarke From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Clarke Bishop Sent: Tuesday, August 11, 2009 10:07 AM To: discussion@acfug.org Subject: [ACFUG Discuss] Learning a ColdFusion Framework: Update I was originally going to start with ColdBox to learn a ColdFusion framework. But, I quickly got lost in the complexity. To really use ColdBox, you end up needing to know Coldspring and Transfer. But, since each of those has a learning curve, it really makes things hard. So, I switched to CFWheels (http://cfwheels.org/ ). Wheels is a ColdFusion framework based on Ruby on Rails. Just like Rails, the CFWheels framework use an active record approach, so there's no need for Transfer or Reactor. And, the object dependencies are also managed by the framework, so you don't need Coldspring. There's still a lot to learn because you have to learn to think the way the framework expects. And, you have to learn the conventions for how things should be named, etc. I found a great book that helped me adjust my thinking - Head First Rails. But, it's Ruby/Rails, of course. I've found that the ideas translate fairly easily to CFWheels, and I've started converting the apps in the book to CFWheels. To help me learn it more deeply, I decided to blog about the process, so if you want, take a look at: http://www.resultantsys.com/index.php/coldfusion/cfwheels-scaffolding-basics / Thanks again for all the ideas and support I got from you guys. I'll keep you posted on my progress! Clarke - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework: Update
Clarke, I used to be on the mailing list for CF Wheels in earlier versions. It has a solid approach. Now, one of your statements about your selection of a framework mentions that Transfer or Reactor was a learning curve point. My warning to you is that in the built in model syntax of CF Wheels, that you are trading perhaps one syntax for another. I will conceded that both Reactor and Transfer are quite more robust in features and nuance, but there is still an object hierarchy that can resemble other ORM approaches. There is an appeal to using a file system based framework to determine dependencies on your view and controller. Also, there is a lexicon of functions in CF Wheels you will need to get familiar with. Some of these are to create code for you. They are handy to use, but I would learn what code is generated upon using these functions. Once you understand what these functions are doing, you may want to move away from some of them as you will probably need to code more strictly or have requirements that the generic functions do not handle. Teddy R. Payne, ACCFD Google Talk - teddyrpa...@gmail.com On Tue, Aug 11, 2009 at 10:07 AM, Clarke Bishop cbis...@resultantsys.comwrote: I was originally going to start with ColdBox to learn a ColdFusion framework. But, I quickly got lost in the complexity. To really use ColdBox, you end up needing to know Coldspring and Transfer. But, since each of those has a learning curve, it really makes things hard. So, I switched to CFWheels (http://cfwheels.org/ ). Wheels is a ColdFusion framework based on Ruby on Rails. Just like Rails, the CFWheels framework use an active record approach, so there’s no need for Transfer or Reactor. And, the object dependencies are also managed by the framework, so you don’t need Coldspring. There’s still a lot to learn because you have to learn to think the way the framework expects. And, you have to learn the conventions for how things should be named, etc. I found a great book that helped me adjust my thinking – Head First Rails. But, it’s Ruby/Rails, of course. I’ve found that the ideas translate fairly easily to CFWheels, and I’ve started converting the apps in the book to CFWheels. To help me learn it more deeply, I decided to blog about the process, so if you want, take a look at: http://www.resultantsys.com/index.php/coldfusion/cfwheels-scaffolding-basics/ Thanks again for all the ideas and support I got from you guys. I’ll keep you posted on my progress! Clarke - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com -
[ACFUG Discuss] Learning a ColdFusion Framework: Update
I was originally going to start with ColdBox to learn a ColdFusion framework. But, I quickly got lost in the complexity. To really use ColdBox, you end up needing to know Coldspring and Transfer. But, since each of those has a learning curve, it really makes things hard. So, I switched to CFWheels (http://cfwheels.org/ ). Wheels is a ColdFusion framework based on Ruby on Rails. Just like Rails, the CFWheels framework use an active record approach, so there's no need for Transfer or Reactor. And, the object dependencies are also managed by the framework, so you don't need Coldspring. There's still a lot to learn because you have to learn to think the way the framework expects. And, you have to learn the conventions for how things should be named, etc. I found a great book that helped me adjust my thinking - Head First Rails. But, it's Ruby/Rails, of course. I've found that the ideas translate fairly easily to CFWheels, and I've started converting the apps in the book to CFWheels. To help me learn it more deeply, I decided to blog about the process, so if you want, take a look at: http://www.resultantsys.com/index.php/coldfusion/cfwheels-scaffolding-basics / Thanks again for all the ideas and support I got from you guys. I'll keep you posted on my progress! Clarke - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
Just to note on FW1 it is very small. I think Sean is trying to bridge the gap between procedural and fusebox people and the heavier frameworks. FW1 is light and design to be easy to use. Should come in handy for certain apps. John ma...@fusionlink.com Douglas Knudsen wrote: to add to this whole topic http://corfield.org/blog/index.cfm/do/blog.entry/entry/Introducing_FW1 Mr Corfield is at work on yet another framework Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Mon, Jul 20, 2009 at 3:32 PM, Dean H. Saxe d...@fullfrontalnerdity.com mailto:d...@fullfrontalnerdity.com wrote: That's the point of MVC. The view is independent of the controller and the data (er, model). -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com mailto:d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 2:48 PM, Jonathan Burnham wrote: My understanding is your model is a model of the application data, and the data resulting from a call to an event is rendered in place of the view. The controller orchestrates everything up through the data rendering, then your front-end technology consumes the data for display. I guess in a general sense we're still talking MVC concepts, but the framework itself doesn't render the view, and you are not accessing any of the framework from the view. On Mon, Jul 20, 2009 at 2:26 PM, Dean H. Saxe d...@fullfrontalnerdity.com mailto:d...@fullfrontalnerdity.com wrote: The data is the model. The view is Flex/Ajax. -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com mailto:d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 2:21 PM, Jonathan Burnham wrote: I'd argue that by using Flex or Ajax you are not using MVC anymore, but you are using a remote event-driven framework. The M C would still be there, but the framework doesn't render a view - it's rendering data. On Mon, Jul 20, 2009 at 2:04 PM, Dean H. Saxe d...@fullfrontalnerdity.com mailto:d...@fullfrontalnerdity.com wrote: ORM has nothing to do with MVC. ORM is all about mapping objects to relational databases. One can use MVC without objects and without a relational database. Conversely, one can use an ORM without using MVC. So the two sets of frameworks should not be confused. -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com mailto:d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 1:56 PM, Douglas Knudsen wrote: I'd argue that if you can't use one of these MVC frameworks with Flex or AJAX, it might not be so MVC, eh? :) Also to point out, ORMs are really a extension of these tools mentioned, they are not MVC frameworks on their own. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Mon, Jul 20, 2009 at 11:31 AM, Teddy R. Payne teddyrpa...@gmail.com mailto:teddyrpa...@gmail.com wrote: Flex calling a framework is a nice feature. Model-Glue, unless it has changed recently, takes advantage of ColdSpring. Using the RemoteObjectProxy in ColdSpring made it pretty simple to create a webservice that calls the result of several dependent CFC objects created in the application to be available as a webservice. The RemoteObjectProxy also obfuscates the original CFC and it dependent objects as the invocation code doesn't exist in the generated proxy. I see from the ColdBox architectural framework graphic that ColdBox mentions LightWire. I would have to see how this would be achieved in LightWire. So, without using a Flex framework, my CFC calls are definitely made easier when I consume a RemoteObject in Flex. The caveat here is that ColdSpring or LightWire is YAF (Yet Another Framework). Teddy - To unsubscribe from this list, manage your profile @http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com
Re: [ACFUG Discuss] Learning a ColdFusion Framework
Just to add to this discussion, the 'model' in mvc will contain services, gateways, value objects, etc. These components (cfc based 99% of the time) interact with either another application (which may be an entirely different MVC app) or a database engine (which you could yet again be considered to be a separate external app) that simply provides data. Important thing to note, most databases are relational so the model will convert that logic to an object oriented picture for the app to use. So instead of using a query object like a spreadsheet, you convert to a list of objects (like value objects). Look at Transfer and the new CF9 Hibernate features to see how this logic works. Now, the key difference between any MVC framework is in the controller logic. The views should be essentially the same: containing things like forms, data lists, and similar presentation logic. The 'view' contains cfoutput, html, javascript, but NOT service calls like cfquery or cfhttp. Service calls are in the 'model'. The model can actually be rather complex in itself, but should again be independent of the MVC logic. Your 'views' and 'model' should not be very different based on your framework choice. However, the controller is where the real differences exist between the frameworks. One is not naturally better than another. Some don't scale as well like a front controller frameworks, but most of the decisions at this point deal with your comfort in programming. In the CF MVC world, you have several different types of controllers to work with.. Framework Controller Logic Explanation (what does that fancy tern mean) Homebaked Usually a Front Controller Direct call to services (usually very tighly coupled between view logic and model service calls) Fusebox Front Controller Direct call to services (tight coupling between view and model) Mach-II Implicit Invocation (Observer pattern) Events are fired which a listener then handles and calls services (loose coupling between views and model) Model-Glue Implicit Invocation (Observer pattern) Events are fired which a listener then handles and calls services (loose coupling between views and model) Coldbox Convention over Configuration (CoC) Also event driven but no xml configuration. Naming and convention handles the controlling logic (medium coupling in my view - but some may argue this point) Coldspring is not a MVC framework in itself. It's a object creation tool to help with object (cfc) dependencies and such. If you do use one the advance frameworks and properly code out your 'model', then coldspring will come in very handy. As a fyi, it follows the factory design and Inversion of Control (IoC) patterns. - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
If you look in the ReadMe on the root of the SVN, I think he says that is a sample app. On Tuesday, July 21, 2009, Teddy R. Payne teddyrpa...@gmail.com wrote: I read through the wiki for FW/1. For something small, there is still some nuance there. I see some code examples and where to put various files, but a sample application is what is really needed there. Perhaps I missed the location of the sample application. From what he is describing is probably the gap between a large framework and creating a more organized code structure. You don't have to have something monolithic to have code and directory structure standards. A set location for views, your controller, a bean factory, and a place to reference model data is really the basis for any application. Sean just added some extra wiring to interpret from a directory structure instead of defining explicitly the connections between the M, V, and C. Teddy -- -- Howard Fore, howard.f...@hofo.com The worthwhile problems are the ones you can really solve or help solve, the ones you can really contribute something to. ... No problem is too small or too trivial if we can really do something about it. - Richard P. Feynman - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
Clarke, So far, everyone's been very even-handed about not really recommending one framework. And while I won't contradict that (in fact, I'll +1 it), I'll say that I'm very, very comfortable with Model-Glue. I used Mach-II in its pre-1.0 days, and for a while after. And I have less than no knowledge about using its current iteration -- which is very different from the one I used. But I tried Model-Glue shortly after Joe Rinehart began releasing betas, and it just felt right from the beginning. Now, that's a very personal thing, separate from any religious debates about which is better. And I have a feeling that if you try the various frameworks, you'll fairly quickly find one that clicks for you personally. As I said, for me it's Model-Glue, which is once again being very actively developed, after a period of time during which Joe Rinehart was unable to spend time on it. Now it's being shepherded along by some very smart folks. That said, there are also many people who seem to have found that same kind of comfort with ColdBox. One thing I'd suggest -- aside from the obvious try-'em-all-out advice -- is to join the mailing lists for each framework you're considering. Lurking on those lists will give you a perspective on how the developers currently using those frameworks think and work, as well as how actively involved in the lists the folks who are maintaining the frameworks are. Safe to say, all three of the MVC frameworks - including the baby of the bunch, ColdBox - are actually quite mature. To add one more item to the ORM discussion: a critical difference between Hibernate and Transfer or Reactor is that the former offers the ability to design your model first, then create the database from that model. That may or may not be important to any of us. But some folks who've used Hibernate for a good while, and who have lived in object model land for a while, are strong advocates of working this way. Teddy's right, of course: it's entirely possible that Reactor or Transfer may later work with or through Hibernate, to make use of that framework's capabilities. Certainly, Mark Mandel, the developer of Transfer, knows Hibernate through and through. He's already written an Adobe DevNet article on the the CF9 ORM capabilities, even though one could think of those capabilities as competing with Transfer, or making it obsolete. -- Thanks, Tom Tom McNeer MediumCool http://www.mediumcool.com 1735 Johnson Road NE Atlanta, GA 30306 404.589.0560
RE: [ACFUG Discuss] Learning a ColdFusion Framework
Thanks Teddy and Tom for your ideas! I watched another one of Charlie’s CFMeetup preso’s – This one by Isaac Dealy. The topic was: Comparing CF Frameworks, a practical demonstration. https://admin.na3.acrobat.com/_a204547676/p54833624/ http://on.tapogee.com/galleonproject/index.html Isaac is the author of onTap, but he does a good job of disclosing his bias! He took Ray Camden’s Galleon project and ported it to all the main frameworks. I thought he made several excellent points: · It’s more important to pick a framework (any framework) than which framework you pick! · The frameworks are more similar than different. And, once you’ve learned any framework, it’s easier to learn another one. This means don’t worry too much about how long the framework will be around! · Good ideas introduced in one framework are usually quickly copied by the others. · Charlie did a poll and about half of the audience used one or more frameworks. The other half didn’t. · Teddy’s advice to build an app in several frameworks is the best practice. But, this is very hard and time consuming for someone like me who has a steep learning curve to go down. This is why Isaac did the comparison for us. He really did a great job of covering the similarities and difference between the frameworks (See the URL above). Based on the preso’s I’ve watched and my research, I think I should take my best guess and just pick a framework. Once I’ve gone a ways down the learning curve, maybe I’ll try some of the others. Tom said, Model-Glue feels more comfortable than Mach-II. And it looks that way to me, too. But, unless one of you says “Oh My, that’s a big mistake!”, I’m going to start with ColdBox. Why? · ColdBox has really great documentation, and I think that will be a big advantage in learning it. · They seem to have a nice layout manager for the views. The way they did this makes some sense to me. · They give you some useful plug-ins and tools. It looks like they are trying to save me time and make development easier. · They have a nice proxy that lets you access the framework via Flex (I know, some of the others have this too, but theirs looks easier to use). · It’s an MVC framework and seems to be mainstream with substantial support behind it. I’m also taking Teddy’s advice and I’ve signed up for the ColdBox eMail list. I’ll keep you posted on my progress! Clarke From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Teddy R. Payne Sent: Sunday, July 19, 2009 4:53 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Learning a ColdFusion Framework Clarke, You have established some criteria in your decision already. You are looking for an MVC framework in ColdFusion. * Mach-II http://en.wikipedia.org/wiki/Mach-II A framework that focuses on trying to ease software development and maintenance * Model-Glue http://en.wikipedia.org/wiki/Model-Glue Through a simple implementation of Implicit Invocation and Model–View–Controller, they allow applications to be well organized without sacrificing flexibility. * Fusebox http://en.wikipedia.org/wiki/Fusebox_%28programming%29 Fusebox does not force the Model–View–Controller (MVC) pattern or Object-Oriented Programming (OOP) on the developer. However, either or both of these development approaches can be used with Fusebox. * PureMVC http://en.wikipedia.org/wiki/PureMVC Framework for ColdFusion * Coldbox http://en.wikipedia.org/w/index.php?title=Coldboxaction=editredlink=1 is an event-driven conventions based MVC ColdFusion Framework with an extensive array of patterns for its operations such as Factories, Helpers, Workers, etc. * Switchboard http://switchboard.riaforge.org/ is a MVC framework with built in authentication, redirecting, and URL routing. The above was pulled from wikipedia on the MVC design pattern. The longevity of any given open source software is not a constant and can be unpredictable. I have no knowledge on Switchboard and I am not sure on the longevity of PureMVC. Your approach to learn what is involved in an MVC framework probably should probably have two approaches: Design Pattern understanding and Practical usage. I would suggest learning the practical usage first with each of the frameworks that make your cut. I would choose two or three at max. Establish what features that you can leverage from each framework. I like to look at things like how easy is it to incorporate other technologies into the framework. Aside from a feature list, perform a Pet Store project in each framework. By Pet Store, learn how to create a form, submit a form, create a model layer for the forms without using built in features like scaffolding. How hard is it to track the data through the framework? How quickly can you learn where to make the changes
Re: [ACFUG Discuss] Learning a ColdFusion Framework
You won't be disappointed with ColdBox. On Mon, Jul 20, 2009 at 11:07 AM, Clarke Bishop cbis...@resultantsys.comwrote: Thanks Teddy and Tom for your ideas! I watched another one of Charlie’s CFMeetup preso’s – This one by Isaac Dealy. The topic was: Comparing CF Frameworks, a practical demonstration. https://admin.na3.acrobat.com/_a204547676/p54833624/ http://on.tapogee.com/galleonproject/index.html Isaac is the author of onTap, but he does a good job of disclosing his bias! He took Ray Camden’s Galleon project and ported it to all the main frameworks. I thought he made several excellent points: · It’s more important to pick a framework (any framework) than which framework you pick! · The frameworks are more similar than different. And, once you’ve learned any framework, it’s easier to learn another one. This means don’t worry too much about how long the framework will be around! · Good ideas introduced in one framework are usually quickly copied by the others. · Charlie did a poll and about half of the audience used one or more frameworks. The other half didn’t. · Teddy’s advice to build an app in several frameworks is the best practice. But, this is very hard and time consuming for someone like me who has a steep learning curve to go down. This is why Isaac did the comparison for us. He really did a great job of covering the similarities and difference between the frameworks (See the URL above). Based on the preso’s I’ve watched and my research, I think I should take my best guess and just pick a framework. Once I’ve gone a ways down the learning curve, maybe I’ll try some of the others. Tom said, Model-Glue feels more comfortable than Mach-II. And it looks that way to me, too. But, unless one of you says “Oh My, that’s a big mistake!”, I’m going to start with ColdBox. Why? · ColdBox has really great documentation, and I think that will be a big advantage in learning it. · They seem to have a nice layout manager for the views. The way they did this makes some sense to me. · They give you some useful plug-ins and tools. It looks like they are trying to save me time and make development easier. · They have a nice proxy that lets you access the framework via Flex (I know, some of the others have this too, but theirs looks easier to use). · It’s an MVC framework and seems to be mainstream with substantial support behind it. I’m also taking Teddy’s advice and I’ve signed up for the ColdBox eMail list. I’ll keep you posted on my progress! Clarke *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Teddy R. Payne *Sent:* Sunday, July 19, 2009 4:53 PM *To:* discussion@acfug.org *Subject:* Re: [ACFUG Discuss] Learning a ColdFusion Framework Clarke, You have established some criteria in your decision already. You are looking for an MVC framework in ColdFusion. - Mach-II http://en.wikipedia.org/wiki/Mach-II A framework that focuses on trying to ease software development and maintenance - Model-Glue http://en.wikipedia.org/wiki/Model-Glue Through a simple implementation of Implicit Invocation and Model–View–Controller, they allow applications to be well organized without sacrificing flexibility. - Fusebox http://en.wikipedia.org/wiki/Fusebox_%28programming%29Fusebox does not force the Model–View–Controller (MVC) pattern or Object-Oriented Programming (OOP) on the developer. However, either or both of these development approaches can be used with Fusebox. - PureMVC http://en.wikipedia.org/wiki/PureMVC Framework for ColdFusion - Coldboxhttp://en.wikipedia.org/w/index.php?title=Coldboxaction=editredlink=1is an event-driven conventions based MVC ColdFusion Framework with an extensive array of patterns for its operations such as Factories, Helpers, Workers, etc. - Switchboard http://switchboard.riaforge.org/ is a MVC framework with built in authentication, redirecting, and URL routing. The above was pulled from wikipedia on the MVC design pattern. The longevity of any given open source software is not a constant and can be unpredictable. I have no knowledge on Switchboard and I am not sure on the longevity of PureMVC. Your approach to learn what is involved in an MVC framework probably should probably have two approaches: Design Pattern understanding and Practical usage. I would suggest learning the practical usage first with each of the frameworks that make your cut. I would choose two or three at max. Establish what features that you can leverage from each framework. I like to look at things like how easy is it to incorporate other technologies into the framework. Aside from a feature list, perform a Pet Store project in each framework. By Pet Store, learn how to create a form, submit a form, create a model layer for the forms without
Re: [ACFUG Discuss] Learning a ColdFusion Framework
Clarke, Tom said, Model-Glue feels more comfortable than Mach-II. Well, I said to me. YMMV. But, unless one of you says “Oh My, that’s a big mistake!”, I’m going to start with ColdBox. Not a bit. Luis Majano has done a pretty amazing job. I just haven't had the time to give ColdBox a real try. It is certainly true that the major authors of each framework have learned from the earlier frameworks -- not just in how they think their framework should function, but in how it should be documented and extended, too. ColdBox is the youngest, and as a result, has more stuff. Frankly, I wish I had the time to give ColdBox a shot. · They have a nice proxy that lets you access the framework via Flex (I know, some of the others have this too, but theirs looks easier to use). Welcome to yet another framework decision: what to use inside Flex. (That was a discussion on the AFFUG list last week.) Have fun. -- Thanks, Tom Tom McNeer MediumCool http://www.mediumcool.com 1735 Johnson Road NE Atlanta, GA 30306 404.589.0560
Re: [ACFUG Discuss] Learning a ColdFusion Framework
Flex calling a framework is a nice feature. Model-Glue, unless it has changed recently, takes advantage of ColdSpring. Using the RemoteObjectProxy in ColdSpring made it pretty simple to create a webservice that calls the result of several dependent CFC objects created in the application to be available as a webservice. The RemoteObjectProxy also obfuscates the original CFC and it dependent objects as the invocation code doesn't exist in the generated proxy. I see from the ColdBox architectural framework graphic that ColdBox mentions LightWire. I would have to see how this would be achieved in LightWire. So, without using a Flex framework, my CFC calls are definitely made easier when I consume a RemoteObject in Flex. The caveat here is that ColdSpring or LightWire is YAF (Yet Another Framework). Teddy
RE: [ACFUG Discuss] Learning a ColdFusion Framework
On top of what Teddy offered in reply to your question, Tim, I’d point out as well that despite CF9 having ORM built-in, the other ORM frameworks could continue to exist for years if only to serve those who don’t move to 9 (there’s traditionally a long slow march to any new release, taking years before even most are on it). That said, of course, I do expect that Transfer will evolve simply because Mark likes to keep it updated for even those on the latest/greatest CF version. And as Tom noted, he’s writing actively about the CF9 ORM stuff as well. As for Reactor (not to be confused with FusionReactor), that’s harder to guess. We don’t see as much press about it, and it may even seem that Transfer and the CF9 ORM may be taking wind from its sails, but their build history shows it’s still actively updated: http://www.zen49396.zen.co.uk/reactor/?C=M;O=D Hope that’s helpful. /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Teddy R. Payne Sent: Sunday, July 19, 2009 5:06 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Learning a ColdFusion Framework Tim, snip If anything, it is a possible new approach that can be an option for future release of frameworks. I do not think it will make any existing ORM frameworks null and void as adoption rates of CF servers, currently existing applications, and time/developer hour investment to change out currently embedded ORM(s). If you are creating something brand new, this is definitely future fodder for some late nights of introspection. Cheers, Teddy - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
I'd argue that if you can't use one of these MVC frameworks with Flex or AJAX, it might not be so MVC, eh? :) Also to point out, ORMs are really a extension of these tools mentioned, they are not MVC frameworks on their own. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Mon, Jul 20, 2009 at 11:31 AM, Teddy R. Payne teddyrpa...@gmail.comwrote: Flex calling a framework is a nice feature. Model-Glue, unless it has changed recently, takes advantage of ColdSpring. Using the RemoteObjectProxy in ColdSpring made it pretty simple to create a webservice that calls the result of several dependent CFC objects created in the application to be available as a webservice. The RemoteObjectProxy also obfuscates the original CFC and it dependent objects as the invocation code doesn't exist in the generated proxy. I see from the ColdBox architectural framework graphic that ColdBox mentions LightWire. I would have to see how this would be achieved in LightWire. So, without using a Flex framework, my CFC calls are definitely made easier when I consume a RemoteObject in Flex. The caveat here is that ColdSpring or LightWire is YAF (Yet Another Framework). Teddy
Re: [ACFUG Discuss] Learning a ColdFusion Framework
ORM has nothing to do with MVC. ORM is all about mapping objects to relational databases. One can use MVC without objects and without a relational database. Conversely, one can use an ORM without using MVC. So the two sets of frameworks should not be confused. -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 1:56 PM, Douglas Knudsen wrote: I'd argue that if you can't use one of these MVC frameworks with Flex or AJAX, it might not be so MVC, eh? :) Also to point out, ORMs are really a extension of these tools mentioned, they are not MVC frameworks on their own. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Mon, Jul 20, 2009 at 11:31 AM, Teddy R. Payne teddyrpa...@gmail.com wrote: Flex calling a framework is a nice feature. Model-Glue, unless it has changed recently, takes advantage of ColdSpring. Using the RemoteObjectProxy in ColdSpring made it pretty simple to create a webservice that calls the result of several dependent CFC objects created in the application to be available as a webservice. The RemoteObjectProxy also obfuscates the original CFC and it dependent objects as the invocation code doesn't exist in the generated proxy. I see from the ColdBox architectural framework graphic that ColdBox mentions LightWire. I would have to see how this would be achieved in LightWire. So, without using a Flex framework, my CFC calls are definitely made easier when I consume a RemoteObject in Flex. The caveat here is that ColdSpring or LightWire is YAF (Yet Another Framework). Teddy - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
I'd argue that by using Flex or Ajax you are not using MVC anymore, but you are using a remote event-driven framework. The M C would still be there, but the framework doesn't render a view - it's rendering data. On Mon, Jul 20, 2009 at 2:04 PM, Dean H. Saxe d...@fullfrontalnerdity.comwrote: ORM has nothing to do with MVC. ORM is all about mapping objects to relational databases. One can use MVC without objects and without a relational database. Conversely, one can use an ORM without using MVC. So the two sets of frameworks should not be confused. -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 1:56 PM, Douglas Knudsen wrote: I'd argue that if you can't use one of these MVC frameworks with Flex or AJAX, it might not be so MVC, eh? :) Also to point out, ORMs are really a extension of these tools mentioned, they are not MVC frameworks on their own. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Mon, Jul 20, 2009 at 11:31 AM, Teddy R. Payne teddyrpa...@gmail.com wrote: Flex calling a framework is a nice feature. Model-Glue, unless it has changed recently, takes advantage of ColdSpring. Using the RemoteObjectProxy in ColdSpring made it pretty simple to create a webservice that calls the result of several dependent CFC objects created in the application to be available as a webservice. The RemoteObjectProxy also obfuscates the original CFC and it dependent objects as the invocation code doesn't exist in the generated proxy. I see from the ColdBox architectural framework graphic that ColdBox mentions LightWire. I would have to see how this would be achieved in LightWire. So, without using a Flex framework, my CFC calls are definitely made easier when I consume a RemoteObject in Flex. The caveat here is that ColdSpring or LightWire is YAF (Yet Another Framework). Teddy - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformhttp://www.acfug.org/?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
My understanding is your model is a model of the application data, and the data resulting from a call to an event is rendered in place of the view. The controller orchestrates everything up through the data rendering, then your front-end technology consumes the data for display. I guess in a general sense we're still talking MVC concepts, but the framework itself doesn't render the view, and you are not accessing any of the framework from the view. On Mon, Jul 20, 2009 at 2:26 PM, Dean H. Saxe d...@fullfrontalnerdity.comwrote: The data is the model. The view is Flex/Ajax. -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 2:21 PM, Jonathan Burnham wrote: I'd argue that by using Flex or Ajax you are not using MVC anymore, but you are using a remote event-driven framework. The M C would still be there, but the framework doesn't render a view - it's rendering data. On Mon, Jul 20, 2009 at 2:04 PM, Dean H. Saxe d...@fullfrontalnerdity.com wrote: ORM has nothing to do with MVC. ORM is all about mapping objects to relational databases. One can use MVC without objects and without a relational database. Conversely, one can use an ORM without using MVC. So the two sets of frameworks should not be confused. -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 1:56 PM, Douglas Knudsen wrote: I'd argue that if you can't use one of these MVC frameworks with Flex or AJAX, it might not be so MVC, eh? :) Also to point out, ORMs are really a extension of these tools mentioned, they are not MVC frameworks on their own. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Mon, Jul 20, 2009 at 11:31 AM, Teddy R. Payne teddyrpa...@gmail.com wrote: Flex calling a framework is a nice feature. Model-Glue, unless it has changed recently, takes advantage of ColdSpring. Using the RemoteObjectProxy in ColdSpring made it pretty simple to create a webservice that calls the result of several dependent CFC objects created in the application to be available as a webservice. The RemoteObjectProxy also obfuscates the original CFC and it dependent objects as the invocation code doesn't exist in the generated proxy. I see from the ColdBox architectural framework graphic that ColdBox mentions LightWire. I would have to see how this would be achieved in LightWire. So, without using a Flex framework, my CFC calls are definitely made easier when I consume a RemoteObject in Flex. The caveat here is that ColdSpring or LightWire is YAF (Yet Another Framework). Teddy - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformhttp://www.acfug.org/?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserformhttp://www.acfug.org/?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
On Mon, Jul 20, 2009 at 2:26 PM, Dean H. Saxed...@fullfrontalnerdity.com wrote: The data is the model. The view is Flex/Ajax. Some Flex (AIR) apps store their own data internally in addition to interacting with data on the server. Flex apps can have their own controllers, and their own model. Sometimes these resemble the server model, sometimes it doesn't. Really, I think MVC doesn't explain server connected Flex apps very well. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
That's the point of MVC. The view is independent of the controller and the data (er, model). -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 2:48 PM, Jonathan Burnham wrote: My understanding is your model is a model of the application data, and the data resulting from a call to an event is rendered in place of the view. The controller orchestrates everything up through the data rendering, then your front-end technology consumes the data for display. I guess in a general sense we're still talking MVC concepts, but the framework itself doesn't render the view, and you are not accessing any of the framework from the view. On Mon, Jul 20, 2009 at 2:26 PM, Dean H. Saxe d...@fullfrontalnerdity.com wrote: The data is the model. The view is Flex/Ajax. -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 2:21 PM, Jonathan Burnham wrote: I'd argue that by using Flex or Ajax you are not using MVC anymore, but you are using a remote event-driven framework. The M C would still be there, but the framework doesn't render a view - it's rendering data. On Mon, Jul 20, 2009 at 2:04 PM, Dean H. Saxe d...@fullfrontalnerdity.com wrote: ORM has nothing to do with MVC. ORM is all about mapping objects to relational databases. One can use MVC without objects and without a relational database. Conversely, one can use an ORM without using MVC. So the two sets of frameworks should not be confused. -dhs -- Dean H. Saxe d...@fullfrontalnerdity.com A true conservationist is a person who knows that the world is not given by his fathers, but borrowed from his children. -- John James Audubon On Jul 20, 2009, at 1:56 PM, Douglas Knudsen wrote: I'd argue that if you can't use one of these MVC frameworks with Flex or AJAX, it might not be so MVC, eh? :) Also to point out, ORMs are really a extension of these tools mentioned, they are not MVC frameworks on their own. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Mon, Jul 20, 2009 at 11:31 AM, Teddy R. Payne teddyrpa...@gmail.com wrote: Flex calling a framework is a nice feature. Model-Glue, unless it has changed recently, takes advantage of ColdSpring. Using the RemoteObjectProxy in ColdSpring made it pretty simple to create a webservice that calls the result of several dependent CFC objects created in the application to be available as a webservice. The RemoteObjectProxy also obfuscates the original CFC and it dependent objects as the invocation code doesn't exist in the generated proxy. I see from the ColdBox architectural framework graphic that ColdBox mentions LightWire. I would have to see how this would be achieved in LightWire. So, without using a Flex framework, my CFC calls are definitely made easier when I consume a RemoteObject in Flex. The caveat here is that ColdSpring or LightWire is YAF (Yet Another Framework). Teddy - To unsubscribe from this list, manage your profile @http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
RE: [ACFUG Discuss] Learning a ColdFusion Framework
Charlie, I saw your post I it started me thinking. With the new feature within CF9 does this make the ORM framework more or less attractive as an option. CF9 seems to handle ORM requirements very well. Would one be better off taking advantage of a different framework and handle ORM issues with the built it functionality of CF9? --- On Sat, 7/18/09, Charlie Arehart char...@carehart.org wrote: From: Charlie Arehart char...@carehart.org Subject: RE: [ACFUG Discuss] Learning a ColdFusion Framework To: discussion@acfug.org Date: Saturday, July 18, 2009, 10:39 PM Uh, here it comes, the annual framework debate. :-) I’m only joking, Clarke. It’s a reasonable question. The good news is that you will indeed get opinions. You’ll just have to sift through them. I think the problem with the discussion is that there’s no one good answer. As with so many things, it depends: on yourself, fellow developers (and indeed if there are any), what you do and don’t know about frameworks and patterns in general, how much you’ll be able to reuse the framework (and the knowledge gained getting comfortable), how much time you have, how much you want to be able (or may have to) to contribute to it, and so many other attributes. Besides the big 4 (mach ii, model-glue, fusebox, and coldbox), there are indeed many more. Another that may suit you getting started is cfwheels. I list all the CFML frameworks (that I’ve found) at my CF411 site: http://www.cf411.com/#cffw (Actually, I break it into 3 categories: Application, injection, and ORM frameworks.) I’ll note that we’ve had talks on ColdBox on the meetup before. Check out all past recordings at recordings.coldfusionmeetup.com. There was also an issue of the FusionAuthority Quarterly Update that tried to review the top frameworks (Vol II Issue II, Fall 2006), which while a bit dated may still be helpful. There was also an effort some years ago at trying to create a repository of one example app built in many frameworks: http://www.cfpetmarket.com/. It didn’t really take off, but it’s worth considering in your evaluation effort. Let’s see what others say in general. /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Clarke Bishop Sent: Saturday, July 18, 2009 6:00 PM To: discussion@acfug.org Subject: [ACFUG Discuss] Learning a ColdFusion Framework OK, I’ve finally decided to really learn a ColdFusion framework! But which one? I watched a presentation Sean Corfield did for BACFUG (I found this on Charlie’s UGTV): https://admin.na3.acrobat.com/_a204547676/p71922816/ I think Mach-II is harder to learn and I don’t need it’s capabilities. So, I crossed Mach-II off my list. Before I watched Sean’s presentation, I was thinking Model-Glue was the right one to learn. It seems like I’ve heard more of you talking about Model-Glue than the others. But, in Sean’s presentation, ColdBox seemed like it might be a good choice, too. It seems to have very good documentation which would help me get down the learning curve. What do you guys think? Is there any other mainstream framework I should look at? I want to learn how to effectively use an MVC framework, and I want to pick something that will expand my understanding and won’t be obsolete next year. Other than that, being easiest to learn is probably most important. Thanks for your ideas! Clarke - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Learning a ColdFusion Framework
What did I hear fusebox compared to recently on twitterh. Coldbox sounds promising, it showed up whilst I was away in Flex land. Seems to me, without fanning flames, mach-ii, coldbox, or model glue will be handy dandy to learn. The principles learned in either of these will apply in the future as well as today. Fusebox I would not say that about. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Sat, Jul 18, 2009 at 10:39 PM, Charlie Arehart char...@carehart.orgwrote: Uh, here it comes, the annual framework debate. :-) I’m only joking, Clarke. It’s a reasonable question. The good news is that you will indeed get opinions. You’ll just have to sift through them. I think the problem with the discussion is that there’s no one good answer. As with so many things, it depends: on yourself, fellow developers (and indeed if there are any), what you do and don’t know about frameworks and patterns in general, how much you’ll be able to reuse the framework (and the knowledge gained getting comfortable), how much time you have, how much you want to be able (or may have to) to contribute to it, and so many other attributes. Besides the big 4 (mach ii, model-glue, fusebox, and coldbox), there are indeed many more. Another that may suit you getting started is cfwheels. I list all the CFML frameworks (that I’ve found) at my CF411 site: http://www.cf411.com/#cffw (Actually, I break it into 3 categories: Application, injection, and ORM frameworks.) I’ll note that we’ve had talks on ColdBox on the meetup before. Check out all past recordings at recordings.coldfusionmeetup.com. There was also an issue of the FusionAuthority Quarterly Update that tried to review the top frameworks (Vol II Issue II, Fall 2006), which while a bit dated may still be helpful. There was also an effort some years ago at trying to create a repository of one example app built in many frameworks: http://www.cfpetmarket.com/. It didn’t really take off, but it’s worth considering in your evaluation effort. Let’s see what others say in general. /charlie *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Clarke Bishop *Sent:* Saturday, July 18, 2009 6:00 PM *To:* discussion@acfug.org *Subject:* [ACFUG Discuss] Learning a ColdFusion Framework OK, I’ve finally decided to really learn a ColdFusion framework! But which one? I watched a presentation Sean Corfield did for BACFUG (I found this on Charlie’s UGTV): https://admin.na3.acrobat.com/_a204547676/p71922816/ I think Mach-II is harder to learn and I don’t need it’s capabilities. So, I crossed Mach-II off my list. Before I watched Sean’s presentation, I was thinking Model-Glue was the right one to learn. It seems like I’ve heard more of you talking about Model-Glue than the others. But, in Sean’s presentation, ColdBox seemed like it might be a good choice, too. It seems to have very good documentation which would help me get down the learning curve. What do you guys think? Is there any other mainstream framework I should look at? I want to learn how to effectively use an MVC framework, and I want to pick something that will expand my understanding and won’t be obsolete next year. Other than that, being easiest to learn is probably most important. Thanks for your ideas! Clarke - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com - - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com -
RE: [ACFUG Discuss] Learning a ColdFusion Framework
Thanks guys! I know that for some people choosing a framework becomes a religious question. I started to say something about this in my original message. Instead, I listed some requirements: . An MVC framework (Therefore, no Fusebox). The others are more object oriented. . Helps expand my understanding and won't quickly become obsolete. . Being easier to learn and get started with. I also have a lot of respect for all the ACFUG members. So, if there's already an ACFUG consensus, I'd rather go in that direction. Charlie, I think I remember asking you before if you focused on a specific framework, and you said No. Doug's been in Flex land, and I also had Timothy's question whether CF9 changes anything with its built-in hibernate. I'd love to hear from anyone who recently has been using one of these frameworks. What do you think might be best for me? Thanks again! Clarke From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Douglas Knudsen Sent: Saturday, July 18, 2009 11:03 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Learning a ColdFusion Framework What did I hear fusebox compared to recently on twitterh. Coldbox sounds promising, it showed up whilst I was away in Flex land. Seems to me, without fanning flames, mach-ii, coldbox, or model glue will be handy dandy to learn. The principles learned in either of these will apply in the future as well as today. Fusebox I would not say that about. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Sat, Jul 18, 2009 at 10:39 PM, Charlie Arehart char...@carehart.org wrote: Uh, here it comes, the annual framework debate. :-) I'm only joking, Clarke. It's a reasonable question. The good news is that you will indeed get opinions. You'll just have to sift through them. I think the problem with the discussion is that there's no one good answer. As with so many things, it depends: on yourself, fellow developers (and indeed if there are any), what you do and don't know about frameworks and patterns in general, how much you'll be able to reuse the framework (and the knowledge gained getting comfortable), how much time you have, how much you want to be able (or may have to) to contribute to it, and so many other attributes. Besides the big 4 (mach ii, model-glue, fusebox, and coldbox), there are indeed many more. Another that may suit you getting started is cfwheels. I list all the CFML frameworks (that I've found) at my CF411 site: http://www.cf411.com/#cffw (Actually, I break it into 3 categories: Application, injection, and ORM frameworks.) I'll note that we've had talks on ColdBox on the meetup before. Check out all past recordings at recordings.coldfusionmeetup.com. There was also an issue of the FusionAuthority Quarterly Update that tried to review the top frameworks (Vol II Issue II, Fall 2006), which while a bit dated may still be helpful. There was also an effort some years ago at trying to create a repository of one example app built in many frameworks: http://www.cfpetmarket.com/. It didn't really take off, but it's worth considering in your evaluation effort. Let's see what others say in general. /charlie From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Clarke Bishop Sent: Saturday, July 18, 2009 6:00 PM To: discussion@acfug.org Subject: [ACFUG Discuss] Learning a ColdFusion Framework OK, I've finally decided to really learn a ColdFusion framework! But which one? I watched a presentation Sean Corfield did for BACFUG (I found this on Charlie's UGTV): https://admin.na3.acrobat.com/_a204547676/p71922816/ I think Mach-II is harder to learn and I don't need it's capabilities. So, I crossed Mach-II off my list. Before I watched Sean's presentation, I was thinking Model-Glue was the right one to learn. It seems like I've heard more of you talking about Model-Glue than the others. But, in Sean's presentation, ColdBox seemed like it might be a good choice, too. It seems to have very good documentation which would help me get down the learning curve. What do you guys think? Is there any other mainstream framework I should look at? I want to learn how to effectively use an MVC framework, and I want to pick something that will expand my understanding and won't be obsolete next year. Other than that, being easiest to learn is probably most important. Thanks for your ideas! Clarke - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink http://www.fusionlink.com - - To unsubscribe from
Re: [ACFUG Discuss] Learning a ColdFusion Framework
Clarke, You have established some criteria in your decision already. You are looking for an MVC framework in ColdFusion. - Mach-II http://en.wikipedia.org/wiki/Mach-II A framework that focuses on trying to ease software development and maintenance - Model-Glue http://en.wikipedia.org/wiki/Model-Glue Through a simple implementation of Implicit Invocation and Model–View–Controller, they allow applications to be well organized without sacrificing flexibility. - Fusebox http://en.wikipedia.org/wiki/Fusebox_%28programming%29Fusebox does not force the Model–View–Controller (MVC) pattern or Object-Oriented Programming (OOP) on the developer. However, either or both of these development approaches can be used with Fusebox. - PureMVC http://en.wikipedia.org/wiki/PureMVC Framework for ColdFusion - Coldboxhttp://en.wikipedia.org/w/index.php?title=Coldboxaction=editredlink=1is an event-driven conventions based MVC ColdFusion Framework with an extensive array of patterns for its operations such as Factories, Helpers, Workers, etc. - Switchboard http://switchboard.riaforge.org/ is a MVC framework with built in authentication, redirecting, and URL routing. The above was pulled from wikipedia on the MVC design pattern. The longevity of any given open source software is not a constant and can be unpredictable. I have no knowledge on Switchboard and I am not sure on the longevity of PureMVC. Your approach to learn what is involved in an MVC framework probably should probably have two approaches: Design Pattern understanding and Practical usage. I would suggest learning the practical usage first with each of the frameworks that make your cut. I would choose two or three at max. Establish what features that you can leverage from each framework. I like to look at things like how easy is it to incorporate other technologies into the framework. Aside from a feature list, perform a Pet Store project in each framework. By Pet Store, learn how to create a form, submit a form, create a model layer for the forms without using built in features like scaffolding. How hard is it to track the data through the framework? How quickly can you learn where to make the changes for a form submission? The Design Pattern approach can occur after you make your decision based upon practical usage. Learn what the vernacular means. What parts of the design pattern are present in your chosen framework? You ask the group for their collective interpretation, but most of this is your study of the pattern and how a given framework works for you. You know your aptitude more than us and you know what problems you are trying to solve. Teddy R. Payne, ACCFD Google Talk - teddyrpa...@gmail.com On Sun, Jul 19, 2009 at 2:57 PM, Clarke Bishop cbis...@resultantsys.comwrote: Thanks guys! I know that for some people choosing a framework becomes a religious question. I started to say something about this in my original message. Instead, I listed some requirements: · An MVC framework (Therefore, no Fusebox). The others are more object oriented. · Helps expand my understanding and won’t quickly become obsolete. · Being easier to learn and get started with. I also have a lot of respect for all the ACFUG members. So, if there’s already an ACFUG consensus, I’d rather go in that direction. Charlie, I think I remember asking you before if you focused on a specific framework, and you said “No”. Doug’s been in Flex land, and I also had Timothy’s question whether CF9 changes anything with its built-in hibernate. I’d love to hear from anyone who recently has been using one of these frameworks. What do you think might be best for me? Thanks again! Clarke *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Douglas Knudsen *Sent:* Saturday, July 18, 2009 11:03 PM *To:* discussion@acfug.org *Subject:* Re: [ACFUG Discuss] Learning a ColdFusion Framework What did I hear fusebox compared to recently on twitterh. Coldbox sounds promising, it showed up whilst I was away in Flex land. Seems to me, without fanning flames, mach-ii, coldbox, or model glue will be handy dandy to learn. The principles learned in either of these will apply in the future as well as today. Fusebox I would not say that about. Douglas Knudsen http://www.cubicleman.com this is my signature, like it? On Sat, Jul 18, 2009 at 10:39 PM, Charlie Arehart char...@carehart.org wrote: Uh, here it comes, the annual framework debate. :-) I’m only joking, Clarke. It’s a reasonable question. The good news is that you will indeed get opinions. You’ll just have to sift through them. I think the problem with the discussion is that there’s no one good answer. As with so many things, it depends: on yourself, fellow developers (and indeed if there are any), what you do and don’t know about frameworks and patterns in general, how much you’ll
