Mark Drew (Redux)- cf_etc...

A long while ago, I started a project to do a plugin to develop Fusebox applications using CFEclipse. I stopped using Fusebox and went on to do MG apps and other custom stuff (more webservices that I would rather do to be honest) so the plugin (fusebox3cfe) has laid dormant for a while. I just wanted to ask the community out there, if there is a need/want for a plugin that helps you whilst developing fusebox applications? If so, is there anybody out there that I can shoot questions and would like to make suggestions as to what would help? I understand but dont code it daily enough to know what would increase my workflow (its one thing knowing what the framework does and how to do it, its another to know what all the reptitive tasks and annoyances are) Leave me a comment with your opinions!

I have been thinking on how to implement "generic" framework support in CFEclipse. I apologise if this post seems a bit rambling but its to get some opinions from people out there and to formalise my thinking a little before I go off and develop something. So, What do I mean by generic framework support? Well, making plugins for each framework is kind of hard. Yes, they all have their own way of doing things but way back when I was doing the Fusebox Plugin, I realised the problems, and also saw how much overlap of code there is. To overcome making plugins for each framework, I am thinking that we need to abstract a little what each framework does (with relation to coding and implementing it), the actions and the UI that each would need. Since each of the frameworks is likely to change in time, and maybe new ones come up, we need a way in CFEclipse to be able to modify (like the dictionary files) and add new framework definitions. I am breaking down the issues for implementing framework support and hopefully shake out a way of developing it as follows: Configuration Most frameworks (I am looking at Model-Glue, Fusebox and Mach II) are configured using an XML file, which has a number of nodes that say the flow of actions in your application, the files to include and the settings of your application. Fusebox also has a number of iterators and logic nodes in the XML. I know there are other frameworks out there, which are configured differently, but these are the main ones I am looking at the moment since I have some knowledge of them and they can be generalised. (I should also include Reactor and Coldspring in this) We need a way to say that, for example, "ModelGlue.xml" is a config file and we should open it and treat it differently or that Fusebox.cfm is also a framework file that we want to edit differently. When I was implementing the Fusebox plugin, I run into the problem that I had to create an object (a class) for each node type, now this isnt a problem if the lexicon of a framework is small, but for Fusebox the lexicon is rather large and in fact (correct me if I am wrong) I think you can add your own nodes. This would make it a nightmare of classes that are specific to a framework. Ok, so lets create a generic node that can have a name, a parent and a number of children. Then we name that node, and assign an image to it. Another part of a framework seems to be the base files required when you are creating an application. These files need to be dropped into your application, such as config files, index.cfm etc. I am not talking about the Core Framework Files that you would create a ColdFusion Mapping to, but the ones you will be working, such as the sample application templates for each framework. To address this and also kill another bird with the same sharpened stone, I have an idea of extending the "New File From Template" to creating a "New Project From Template" which would you, as a user would set up by setting a project that you keep all your project templates in and in each folder you can put a set of files that make up a baseline application,e,g a folder called "Normal CF Project" with Application.cfm and index.cfm or a folder called "CFC Project" with Application.cfc and index.cfm or a folder with the Model Glue application template. This would mean that when you are creating a project you can select from which of these folders you would copy the files into your new project. This is fine so far but lacks another part, all the replacements you have to do (for example the name of the application). I though this might be solved by using the snippet syntax in those files e.g <cfapplication name="${{applicationname}"> So a brute force attack would be to parse ALL of the files under that folder looking for snippet texts. Mike Nimer actually suggested something, which would be to copy the files using ANT. This is a very intelligent choice as I can use a generic ANT build file (I am talking in the background, Eclipse running it as part of its project creation script) that I can pass a list of replacements. At the root of each project we would have a xml file that CFEclipse can read, for you to put all the values to replace, then in each of the files you would have variables that are replaced. Views (or UI) What views would you need for your framework? I am thinking currently that we only need two views, one being the Framework File Editor, basically an XML editor that (in the background) knows what DTD to use for that particular framework file and what insight to provide, and a outline view of all the nodes in that file. Well, XML buddy already has a outline view of your xml. If we are re-creating an XML editor for the config files and we have outline view, maybe we could configure it to be filtered (show events for MG, fuse-actions for Fusebox etc) by a particular node. Each node type would then need to have its own action (when you double click etc) and ways to add new nodes (where applicable). Actions Now we can edit our framework files, we need to add actions, I would say that to start out with we have some simple "open" actions assigned to some nodes, so some examples: * For ModelGlue.xml - On node "include", use template, to open file by path * For ModelGlue.xml - On node "include", use template, to open file by path, using "ColdSpring/beans/bean:id=modelGlueConfiguration/property:name=viewMappings" value as the root *For ModelGlue.xml - On node "modelglue/controllers/controller:type" open file by package *For ModelGlue.xml - On node "modelglue/event-handlers/event-handler/broadcast/message:name" open file referenced in "modelglue/controllers/controller/message-listener".parent.type where message:name = message-listener:message These are just examples to get my head round how the actions would need to be worked out. But basically the actions here are open by path or open by package. Other actions would run in the background and they are custom validation, not just XML validation but for example * validate that all "modelglue/event-handlers/event-handler/broadcast/message:name" have a corresponding "modelglue/controllers/controller/message-listener:message" * validate that for "modelglue/controllers/controller/message-listener:function" there is a corresponding cffunction in the "open file by package" for "modelglue/controllers/controller/message-listener"_parent.type As you can see we are starting to get a syntax here of the type of language that we need to define for each framework. So to add framework support this would be done by creating a file for each framework file that we shall handle, it would define where to look for a DTD, define actions per named node, define validations and define nodes that will be displayed in the outline I don't have much experience in this area so I appreciate any comments on my logic so far.

Ben Forta, Sean Corfield, Ray Camden, Spike Milligan in the house. Joe Rinehart, Doug Hughes, Simeon Bateman, Rob Rohan, Ollie Tupman in the house.
Jared Rypka-Hauer, Nathan Strutz,  Mike Nimer, Tim Buntel is out the house. 

Just a little sing song for all the people who have helped and taught me things about ColdFusion and CFEclipse along the way.

THANK YOU!
(Check out the song on )

It has just been confirmed that I shall be presenting CFEclipse at the UK CFUG in London on the 2nd of March. Hope you all can make it (if you are in the country, if not get yourself a plane ticket ASAP!) I will be showing some of the new upcoming features in Fusebox plugin for CFEclipse. If you have any specific areas you would like me to cover, leave me a message

As I mentioned I am back on the development tip with the Fusebox plugin for CFEclipse. I am more concentrating on it working with Fusebox 4.1 than 3 (sorry!) So if you have any requests for features, let me know!

I have been looking into frameworks for a project recently, and have had a number of conversations and basically I think it comes down to preference really. Of course, I have a vested interest since I contribute to CFEclipse as well as have my own plugin for Fusebox over at CFOpen (can you guess my preference yet?) but still I wanted to check out which frameworks are the best for the requirements. Its a lot to go through but Simon Horwith posted about CF Petmarket, a whole site devoted to the Pet Market application built using different frameworks... go check it out!