Mach-II

No, I only used fusebox once for a small project, didn't like it as it fragmented my code to much and there was resistance from other people that didn't want to learn it. You don't have to use a framework for very large projects, just plan it very well at first and document it very well. This might account for a large portion of the 9500h you plan to spent on it. But it is well worth it, even on relatively small projects. [Tom Kitta] http://www.tomkitta.com   - Does your organization use Mach-II?

Tom - Actually, I'm not going to reinvent the wheel and have no interest in going forward without some structure. Working without a framework around here is a lot like herding cats. Mach-II has a number of capabilties that are ideal for what I am planning to do, I just wanted to get some anecdotal pros / cons. It sounds to me like people are concerned over scalability and the learning curve. Anyways, it also doesn't sound like you have ever used Mach-II. M Tom Kitta <tom@energyshop.com> wrote: No, I only used fusebox once for a small project, didn't like it as it fragmented my code to much and there was resistance from other people that didn't want to learn it. You don't have to use a framework for very large projects, just plan it very well at first and document it very well. This might account for a large portion of the 9500h you plan to spent on it. But it is well worth it, even on relatively small projects. [Tom Kitta] http://www.tomkitta.com   - Does your organization use Mach-II? ---------------------------------

If Mach-II is ideal for what you want to do, then by all means use it. My guess was that you were not yet sold on the Mach-II issue and wanted to look over at the alternative approaches to large project development. TK   Tom -   Actually, I'm not going to reinvent the wheel and have no interest in going forward without some structure. Working without a framework around here is a lot like herding cats.   Mach-II has a number of capabilties that are ideal for what I am planning to do, I just wanted to get some anecdotal pros / cons. It sounds to me like people are concerned over scalability and the learning curve.   Anyways, it also doesn't sound like you have ever used Mach-II.   M

At 02:43 PM 5/26/2004, you wrote: I wrote a framework that dynamically creates another framework. It uses a mix of FuseBox, FuseDocs, XML, UML, Mach-4, FB4, MVC, OOP, and OnTap. All built on "pagelets" and CORBA-brokered "portlets" that have overloaded methods and forged method signatures. ;-)

We used mach-ii on a project at my company and I'll agree that there was a steep leaning curve.  If your planning on using it on a large enterprise scale project, I would suggest that maybe a smaller internal project first to work out any bugs in the process.  I did like the framework and the only reason we ended up not using it was because the host the client was on was running 6.0 and not 6.1. Trevor   _____ Sent: Wednesday, May 26, 2004 3:54 PM To: CF-Talk Subject: RE: Mach-II Tom - Actually, I'm not going to reinvent the wheel and have no interest in going forward without some structure. Working without a framework around here is a lot like herding cats. Mach-II has a number of capabilties that are ideal for what I am planning to do, I just wanted to get some anecdotal pros / cons. It sounds to me like people are concerned over scalability and the learning curve. Anyways, it also doesn't sound like you have ever used Mach-II. M Tom Kitta <tom@energyshop.com> wrote: No, I only used fusebox once for a small project, didn't like it as it fragmented my code to much and there was resistance from other people that didn't want to learn it. You don't have to use a framework for very large projects, just plan it very well at first and document it very well. This might account for a large portion of the 9500h you plan to spent on it. But it is well worth it, even on relatively small projects. [Tom Kitta] http://www.tomkitta.com   - Does your organization use Mach-II? ---------------------------------   _____  

Mach-II is great! It may be a bit tricky to learn for starters, since it is some brand new concepts. I am using it extensively, but I haven't managed to sell it to my (conservative) colleagues. I think it is definately something for a bigger project, since then you can plan the whole design using UML tools, and then design each object separately (and unit test them). -- Hugo Ahlenius ------------------------------------------------------------- Hugo Ahlenius                  E-Mail: hugo.ahlenius@grida.no Project Officer                Phone:            +46 8 230460 UNEP GRID-Arendal              Fax:              +46 8 230441 Stockholm Office               Mobile:         +46 733 467111                                WWW:       http://www.grida.no ------------------------------------------------------------- | -----Original Message----- | | Sent: Wednesday, May 26, 2004 19:49 | To: CF-Talk | Subject: OT: Mach-II | | Last summer, there was a lot of optimism on this list | surrounding the release of Mach-II and it's object oriented | approach to ColdFusion. Having tried it on a few projects and | decided Fusebox was better suited for what I was doing, I am | now considering it for a larger project my team is about to | commence (approx. 9,500 man hours over a 7 month period). | | One of my main concerns is having to train people to work | within this framework, I remain one of three or four people | in my organization who have actually heard of Mach-II. There | is some resistance based on people's unfamiliarity with it | and the perception other frameworks are more widely used. | This got me to wondering about how much Mach-II is actually | being used, so I am conducting one of those unscientific | polls about technology usage: | |   - Does your organization use Mach-II? | |   - Care to comment on how your organization has benefited | from using it? | | M | | | |

> just plan it very well at first and document it very well. This might > account for a large portion of the 9500h you plan to spent on > it. But it is well worth it, even on relatively small projects. Tom stated it perfectly. It's all about planning. Well planned projects are more likely to be successful regardless of framework or methodology. Mike

At 06:48 AM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- "No way Jose". Nearly a decade of programming with CF and other languages, I can tell you this is dead wrong. You can plan for 2 years on the best way to cross the Atlantic. If you planned to use a canoe, regardless of how "well" you planned, you're doomed. You're better of flying. The same goes for frameworks. Ever heard the expression that "The road to hell is paved with good intentions."? The same applies for software development. You can plan till the cows come home, but unless you ** build and execute ** the project plan properly, then you are likely in incur steep software maintenance costs. No matter what, the bottom line is that CF needs to execute code, and unless that code is actually structured and written well, you're up the creek, regardless of how well or how much you planned. This is what is missed in the typical "framework" debates. It ** does** matter what framework you use. The notion that "any framework" will work is hogwash! My guess is this notion stems from the fact that CF developers typically work in small groups where they "pick and pull" at an application themselves over time and consider this "maintenance". A large development team (25-50 developers) must rely on a pre-determined contract on how software will be structured and executed to reduce dependence on each other. This is where the framework comes in. Have I used Mach-II? Once, on one project. Will I use it in the future? Without a doubt. Why? Because it provides an incredibly flexible foundation for building web applications that can be (as others have mentioned on this list) maintained and updated with minimal impact on the whole system. This saves money - typically not a concern for someone who's day is filled with deciding between CFSTOREDPROC and CFQUERY. Don't fall for the "some framework is better than none" argument. -- Alex

On May 27, 2004, at 9:36 AM, Alexander Sherwood wrote: >  Have I used Mach-II? Once, on one project. Will I use it in the > future? Without a doubt. Why? Because it provides an incredibly > flexible foundation for building web applications that can be (as > others have mentioned on this list) maintained and updated with > minimal impact on the whole system. In what way is it better at this than Fusebox?  I find that my FB3 apps are extremely modular and can be easily maintained. -- Damien McKenna - Web Developer - dmckenna@thelimucompany.com The Limu Company - http://www.thelimucompany.com/ - 407-804-1014

At 10:14 AM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- In particular, I found extending the base MachII.Listener and the event-based processing to be really, really flexible. Handling complex execution paths (Like Spectra's old PLPs) is quite easy, all while keeping the model or service layer independent of the UI. I am finishing up a ** HUGE ** project that is basically a customizable data entry application. A month ago, the specs were updated to require that all of the services accessed by the UI be made available as a SOAP API, completely devoid of a UI. Very few changes needed to be made because of the way Mach-II requires an application to be structured. It forces separation of UI from the model, and I just don't think FB does this nearly as well. Just my $.02. But if you like FB or OnTap or anyother framework, stick with it, for sure! -- Alex ----- Excess quoted text cut - see Original Post for more -----

The key word here is "likely". Yes, there are things that will fail no matter what as the technology isn't sufficient to reach the goal or the goal is simply impossible or you're trying to do 30 hours of work in a 24 hour day. But for the vast array of tasks that do not fall into that category, there is no substitution for good planning. -- Howard Fore, mylists@hofo.com On May 27, 2004, at 9:36 AM, Alexander Sherwood wrote: ----- Excess quoted text cut - see Original Post for more -----

mmm... Another thing that you aren't mentioning is code reuse -- the thing that goes on between projects, or within parts of sub-projects. I think it helps if you see every move you make as an investment in future projects (and in the maintenance of the current project). In fusebox you have a multitude of small reusable snippets (the fuses), in addition to customtags and the occasional cfc. In Mach-II you create a full backend of interacting CFC that are not tightly coupled with the application can be easily re-used, even by (with the exception of m2 listeners) non-mach-ii applications. Using MVC (mach-ii, with fusebox or any framework) creates more possibilities for this, of course. -- Hugo Ahlenius ------------------------------------------------------------- Hugo Ahlenius                  E-Mail: hugo.ahlenius@grida.no Project Officer                Phone:            +46 8 230460 UNEP GRID-Arendal              Fax:              +46 8 230441 Stockholm Office               Mobile:         +46 733 467111                                WWW:       http://www.grida.no ------------------------------------------------------------- | -----Original Message----- | | Sent: Thursday, May 27, 2004 15:37 | To: CF-Talk | Subject: RE: Mach-II | | At 06:48 AM 5/27/2004, you wrote: | >> just plan it very well at first and document it very well. | This might | >> account for a large portion of the 9500h you plan to spent | on it. But | >> it is well worth it, even on relatively small projects. | > | >Tom stated it perfectly. It's all about planning. Well | planned projects | >are more likely to be successful regardless of framework or | methodology. | | "No way Jose". Nearly a decade of programming with CF and | other languages, I can tell you this is dead wrong. You can | plan for 2 years on the best way to cross the Atlantic. If | you planned to use a canoe, regardless of how "well" you | planned, you're doomed. You're better of flying. The same | goes for frameworks. | | Ever heard the expression that "The road to hell is paved | with good intentions."? The same applies for software | development. You can plan till the cows come home, but unless | you ** build and execute ** the project plan properly, then | you are likely in incur steep software maintenance costs. No | matter what, the bottom line is that CF needs to execute | code, and unless that code is actually structured and written | well, you're up the creek, regardless of how well or how much | you planned. | | This is what is missed in the typical "framework" debates. It | ** does** matter what framework you use. The notion that "any | framework" will work is hogwash! My guess is this notion | stems from the fact that CF developers typically work in | small groups where they "pick and pull" at an application | themselves over time and consider this "maintenance". A large | development team (25-50 developers) must rely on a | pre-determined contract on how software will be structured | and executed to reduce dependence on each other. This is | where the framework comes in. | | Have I used Mach-II? Once, on one project. Will I use it in | the future? Without a doubt. Why? Because it provides an | incredibly flexible foundation for building web applications | that can be (as others have mentioned on this list) | maintained and updated with minimal impact on the whole | system. This saves money - typically not a concern for | someone who's day is filled with deciding between | CFSTOREDPROC and CFQUERY. | | Don't fall for the "some framework is better than none" argument. | | -- | Alex | | |

>>In fusebox you have a multitude of small reusable snippets So called "re-usable" code is not proper to Fuse Box, OOP or any "framework". Re-usable code is just a basic technique that has always been used by any good programmer, period. I started my carreer in the end 60ies, on a 1Mhz 16bit processor with 28k RAM, with no hardware floating arithmetic, and I swear we "Re-used" any %$/" piece of code we could! Even a 10 assembler instructions routine was made re-usable if it could be re-used. And "event programming" is not new either: this 28k processor did use a fairly complex interrupt system with 16 priority levels, processing queue, dispatcher, you name it. Just renaming things like Event instead of Interrupt, Method instead of function, property instead of variable, Information Technologies instead of Computer Science... does not make them any better or newer. It is just a technique used by newcomers to aquire the feeling they have invented the whole thing ;-)) Pretending that OOP or any new technique has introduced re-usable code is the greater joke of all the computer industry in 50 years! ;-)) Frameworks, OOP are just like sects: they set up rules for those who don't know how to behave by themselves; they are just hobble for others. -- _______________________________________ See some cool custom tags here: http://www.contentbox.com/claude/customtags/tagstore.cfm Please send any spam to this address: piegeacon@internetique.com Thanks.

At 10:45 AM 5/27/2004, you wrote: >>>In fusebox you have a multitude of small reusable snippets > >So called "re-usable" code is not proper to Fuse Box, OOP or any "framework". >Re-usable code is just a basic technique that has always been used by any good programmer, period. Right. >I started my carreer in the end 60ies, on a 1Mhz 16bit processor with 28k RAM, with no hardware floating arithmetic, >and I swear we "Re-used" any %$/" piece of code we could! >Even a 10 assembler instructions routine was made re-usable if it could be re-used. Nice. >And "event programming" is not new either: this 28k processor did use a fairly complex interrupt >system with 16 priority levels, processing queue, dispatcher, you name it. Sure, but what did the software do? The point is that software "toolsets" like CFML have so much flexibility, that adopting a standardized way of writing software and modeling interactions between it's pieces is a sound practice. FuseBox, Mach-II, OnTap, etc., just offer different ways to do this. >Pretending that OOP or any new technique has introduced re-usable code is the greater joke of >all the computer industry in 50 years! ;-)) 'Cmon, dude! Are you telling me that writing a subroutine in BASIC that is called twice from 2 different GOTO statements is the same as things like Object Inheritence and polymorphism? I get what your saying, but there are major differences, even if at the root you're looking at the principle of "reuse". >Frameworks, OOP are just like sects: they set up rules for those who don't know how to behave by themselves; >they are just hobble for others. Interesting. The next time you need a tooth pulled, just throw back a shot of Cognac and get out your pliers!  Replacing cognac with Novacain and pliers with sterile forceps is fooey! We walked 5 miles uphill to school...both ways!....... ;-) -- Alex

Claude Schneegans <schneegans@internetique.com> wrote: > So called "re-usable" code is not proper to Fuse Box, OOP or any > "framework". > Re-usable code is just a basic technique that has always been used by any > good programmer, period. I think you are missing the point that each framework emphasises highly decoupled coding practices to reduce the cost of supporting applications over time and increase the resusability of code. These things could be achieved other ways, but some people look at that as reinventing the wheel. This is not something Fusebox or Mach-II make exclusive claims to, but it is something application developers often ignore on their own. > Pretending that OOP or any new technique has introduced re-usable code is > the greater joke of all the computer industry in 50 years! ;-)) Agreed, pretending to have introduced something that has been around for a long time is shameful. No one, to the best of my knowledge, has ever claimed Fusebox or Mach-II are the only way to accomplish this. This is a core synthetic capability of the framework based on the features of the scripting language the application is built with. So I don't really understand your argument. > Frameworks, OOP are just like sects: they set up rules for those who don't > know how to behave by themselves; they are just hobble for others. Frameworks are a means to achieve a predictable result in application development in terms of using a commonly understood set of rules about how an application is organized, designed, and engineered. But I believe we are really just splitting hairs here. Are you saying that every developer on a project should naturally 'know how to behave' and that members of their team should not burden them with boundaries? I think a lot of people would strongly disagree with that idea. M

>>No one, to the best of my knowledge, has ever claimed Fusebox or Mach-II are the only way to accomplish this. I was not speaking about Fusebox in particular, but about OOP in general. And I did not say that OOP claims it is the only way to accomplish this. But when everybody says "OOP allows or enables, or whatever, re-using the code", it promotes the idea that no code was re-used before, and THIS is just not true. OPP makes re-using code just a bit more systematic, no more, and good programers will still re-use code just as before, and even with OOP, bad programmers may not. -- _______________________________________ See some cool custom tags here: http://www.contentbox.com/claude/customtags/tagstore.cfm Please send any spam to this address: piegeacon@internetique.com Thanks.

At 01:47 PM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- I thought Hal Helms invented OOP? ;-)

Maybe I am just living in a hole, but I have never heard anyone say OOP is the original way to reuse code. It sounds like you are complaining that you took something someone said to imply an absurd idea, which by no means makes it true that anyone actually ever said that. Perhaps you can point to a place where someone has claimed OOP is the original means of reusing code? M Claude Schneegans <schneegans@internetique.com> wrote: >>No one, to the best of my knowledge, has ever claimed Fusebox or Mach-II are the only way to accomplish this. I was not speaking about Fusebox in particular, but about OOP in general. And I did not say that OOP claims it is the only way to accomplish this. But when everybody says "OOP allows or enables, or whatever, re-using the code", it promotes the idea that no code was re-used before, and THIS is just not true. OPP makes re-using code just a bit more systematic, no more, and good programers will still re-use code just as before, and even with OOP, bad programmers may not. -- _______________________________________ See some cool custom tags here: http://www.contentbox.com/claude/customtags/tagstore.cfm Please send any spam to this address: piegeacon@internetique.com Thanks. ---------------------------------

>>Perhaps you can point to a place where someone has claimed OOP is the original means of reusing code? No one will claim this in such an acurate way, but one can read alomost every where, like for instance here: http://www.developerfusion.com/show/80/3/ that "OOP allows developers to reuse code and data together through inheritance." Now this tends to make people believe that code reuse was not allowed or possible before OOP and inheritance, and this is just not true. Then another one: By inheriting from predefined objects, developers can more rapidly construct complex applications. Since writing new code always has the potential for incorporating bugs, reusing tested code minimizes the chances of additional bugs. This is absolutely fallacious: this almost claims that there was no predefined objects before OOP and that one had to "rewrite code" in order to reuse it. This not only completely false, it is absolutely ridiculous. Wether some code lies inside a library, in another part of the code or in an OOP object, one can reuse it AND make bugs by not using it the right way, just as well. -- _______________________________________ See some cool custom tags here: http://www.contentbox.com/claude/customtags/tagstore.cfm Please send any spam to this address: piegeacon@internetique.com Thanks.

I'm people. I would not read it that way. Was there supposed to be a disclaimer stating someone else did this before? M Claude Schneegans <schneegans@internetique.com> wrote: >>Perhaps you can point to a place where someone has claimed OOP is the original means of reusing code? No one will claim this in such an acurate way, but one can read alomost every where, like for instance here: http://www.developerfusion.com/show/80/3/ that "OOP allows developers to reuse code and data together through inheritance." Now this tends to make people believe that code reuse was not allowed or possible before OOP and inheritance, and this is just not true. Then another one: By inheriting from predefined objects, developers can more rapidly construct complex applications. Since writing new code always has the potential for incorporating bugs, reusing tested code minimizes the chances of additional bugs. This is absolutely fallacious: this almost claims that there was no predefined objects before OOP and that one had to "rewrite code" in order to reuse it. This not only completely false, it is absolutely ridiculous. Wether some code lies inside a library, in another part of the code or in an OOP object, one can reuse it AND make bugs by not using it the right way, just as well. -- _______________________________________ See some cool custom tags here: http://www.contentbox.com/claude/customtags/tagstore.cfm Please send any spam to this address: piegeacon@internetique.com Thanks. ---------------------------------

Nor did I. -- Howard Fore, mylists@hofo.com On May 27, 2004, at 3:44 PM, Michael Haggerty wrote: ----- Excess quoted text cut - see Original Post for more -----

I can't help but say that your "full backed of interacting CFCs that are not tightly coupled to the app" applies just as much to FB as to Mach-II (and probably most other frameworks).  The fact that it's not tightly coupled to the app necessarily means that its not framework dependant, so you can't use that as an argument for or against any given framework. I've personally taken applications from FB4 -> Mach-II and from Mach-II -> FB4 for various reasons.  And I even have one that's actually a hybrid, because part of it is much better suited to the event model of Mach-II, but most of it is better off as FB (because it's simpler).  In both cases the backend didn't change a lick, which is at is should be.   Cheers, barneyb ----- Excess quoted text cut - see Original Post for more -----

----- Excess quoted text cut - see Original Post for more ----- Maybe people should get together and product MachBox or FuseMach (depending on which way you see it) :P

At 12:59 PM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- Already done. Look for the release of Mach-3, a combination of both FuseBox 4 and Mach-II. Framework should be out mid-July along with mailing lists, web site and documentation. -- Alex ----- Excess quoted text cut - see Original Post for more -----

I'll wait for Mach-3 Turbo ;) -Matt On May 27, 2004, at 1:03 PM, Alexander Sherwood wrote: ----- Excess quoted text cut - see Original Post for more -----

At 01:07 PM 5/27/2004, you wrote: >I'll wait for Mach-3 Turbo ;) Check this out: Battery-powered Mach3 razor uses slight electric charge to life hair off face! http://www.gillette.com/products/grooming_men.asp -- Alex ----- Excess quoted text cut - see Original Post for more -----

> From: Matt Liotta > > I'll wait for Mach-3 Turbo ;) Will the guys at Discovery's Monster Garage making a version of that? <g>

Will I have to spend $15 on a set of blades to use it? -- Howard Fore, mylists@hofo.com On May 27, 2004, at 1:03 PM, Alexander Sherwood wrote: > Look for the release of Mach-3, a combination of both FuseBox 4 and > Mach-II. Framework should be out mid-July along with mailing lists, > web site and documentation.

> "No way Jose". Nearly a decade of programming with CF and > other languages, I can tell you this is dead wrong. You can > plan for 2 years on the best way to cross the Atlantic. If > you planned to use a canoe, regardless of how "well" you > planned, you're doomed. You're better of flying. The same > goes for frameworks. Dead wrong? I disagree. Well planned applications are bound for success. I have been programming for a long time as well, in a lot harder languages than CF and can tell you first hand that a lack of planning and organization directly leads to software failure (among many other reasons but we are talking about planning). Your analogy to crossing the Atlantic in a canoe is not really applicable and off the edge and you know it. Some things are never possible despite the bogus catch-phrase "all things are possible". These are assumed, like your canoe statement. > Ever heard the expression that "The road to hell is paved > with good intentions."? The same applies for software > development. You can plan till the cows come home, but unless > you ** build and execute ** the project plan properly, then > you are likely in incur steep software maintenance costs. I don't pay attention to expressions that much, sorry. I agree that building and executing are important, but I build and execute FROM A PLAN, A WELL THOUGHT OUT WAY TO ACCOMPLISH A TASK. Maintenance of an application is MUCH more easier when the application was well thought out and well planned to begin with because the implementation reflects a well thought out plan. Just because the statistics show that a great percentage of a system goes to maintenance; it should be noted that they are only pointing this out because it shouldn't be that way, planning is what saves you the bucks down the road. That is just the way it is. > No matter what, the bottom line is that CF needs to execute > code, and unless that code is actually structured and written > well, you're up the creek, regardless of how well or how much > you planned. My code is structured and well written, so the emphasis is on the plan. You can't build a house without a blue print, well you could, but you'd do a much better job with a plan... Just like with software development. > This is what is missed in the typical "framework" debates. It > ** does** matter what framework you use. I agree. Whatever works for you. > The notion that "any framework" will work is hogwash! My guess is this notion > stems from the fact that CF developers typically work in > small groups where they "pick and pull" at an application > themselves over time and consider this "maintenance". A large > development team (25-50 developers) must rely on a > pre-determined contract on how software will be structured > and executed to reduce dependence on each other. This is > where the framework comes in. Any framework will due, I don't buy the group size argument... I do agree the "contract" needs to be established and adhered to, but that goes for any framework. ----- Excess quoted text cut - see Original Post for more ----- I have been playing with Mach-II In my spare time and when I get comfortable enough with it will use it more. Fusebox has been my choice for quite some time now and it works great: provides great organization, structure, conventions, etc... This saves money too. > Don't fall for the "some framework is better than none" argument. I have not fallen for anything. -- Mike --

At 09:56 AM 5/27/2004, you wrote: I think we're in agreement, Mike. Sorry if the post seemed directed at you, as that was not my intention. ----- Excess quoted text cut - see Original Post for more ----- Right. But planning "well", by the same token, isn't a guarantee that the project will succeed! >My code is structured and well written, so the emphasis is on the plan. You >can't build a house without a blue print, well you could, but you'd do a >much better job with a plan... Just like with software development. Yup, and this is what I was getting at: even if you have a blueprint, your house will crumble unless the concrete for the foundation is mixed correctly. It will be weak if the primary support beams aren't positioned properly. It will leak water when you flush if the PVC plumbing joints aren't glued correctly....you see what I'm getting at here. Blueprints are great, but unless the plan is ** executed ** and built properly, you can wipe your rear with them! ;-) >I have been playing with Mach-II In my spare time and when I get comfortable >enough with it will use it more. Fusebox has been my choice for quite some >time now and it works great: provides great organization, structure, >conventions, etc... This saves money too. I agree. What gets me is people who claim that Mach-II doesn't "scale well". I'd like to see some empirical evidence of this. I know that leaving debugging enabled in the early days slowed a Mach-II app down, but if you've got debugging turned on a production server then you ought to be <CFLOG>'ed, <CFDUMPED>'ed and <CFFLUSHED>'ed! ;-) What is it with the scatological tags, anyway? What's next? <CFTURTLEHEAD> or <CFMONKEYTAIL>? My point here is that both the "nitty gritty" AND the framework matter....good planning and any framework is not a replacement for writing solid, maintainable software! -- Alex

> I think we're in agreement, Mike. Sorry if the post seemed > directed at you, as that was not my intention. Likewise, 'tis all good. :-) > Right. But planning "well", by the same token, isn't a > guarantee that the project will succeed! Exactly. But you are better off with it... Kind of like car insurance :-) > framework matter....good planning and any framework is not a > replacement for writing solid, maintainable software! I'm following you, but I do think any framework will work as long as it has been proven to be "good" by a majority of the userbase. Joe and Pete from the hotdog stand could write a "framework" but we would assume that unless thye have a good understanding of what frameworks are and how they tie into programming, etc, it will probably not be useful. I am just saying that it should all start with a good solid plan. On top of that should be good solid code. We are on the same page I think.. Mike

Just to stick in my two pennorth, this is something of a pet subject of mine. I wrote an recent article on a similar theme at http://www.headshift.com/archives/001379.cfm There's been some good points on this discussion - I guess my take on it would be that if your planning stage doesn't include "which methodology is most appropriate IN THIS CASE?", then that's insufficient planning, full stop. (or period, for the Americans ;P ) And your consideration of "which methodology is most appropriate" must also include - current in-house expertise - learning curve for a new methodology vs. time constraints for project delivery aswell as the likelihood of future enhancements on this project, etc etc e.g. If you have a shop full of hardcore CFObjects coders, there's no point saying "let's do this job in Fusebox 4 / Mach II / methodology X " if the deadline is tight. I've been using fusebox since 1999, and I think it's great for MOST apps that I've worked on. On the other hand, I've worked on some projects that have been done entirely in fusebox, but STILL been a nightmare because of insufficient planning. In my experience, the more complicated the application, the more disciplined you should be about sticking to your chosen methodology, whatever it is. I'm sure we've all had some rush jobs that we've thought "ah, never mind the full architecture process (or whatever), I'll just hack this together quickly...." Pretty much every single one of those quick hacks has later turned round and bitten me in the arse to some extent. Have I used Mach II ? Yes Will I use it in future ? Yes, certainly, but with a couple of reservations. Like any new way of doing things, it'll take some time to evolve and mature. Fusebox 1 and 2 were fine for their time, but people (myself include) quickly came up against the limitations of it for more complex projects. Several sites would have been much easier if XFB had been around at the time they were written. Likewise, a couple of big XFB sites I did would have turned out much more elegant if FB3 have been around. I can see similar situations with Mach-II now, and I'm sure when the NEXT version of Mach-II arrives, we'll say the same about apps written in Mach-II version 1. You live and learn. Rant over ;) Alistair Alistair Davidson Senior Technical Developer Headshift.com Smarter, Simpler, Social

  I'll point out that writing a subroutine in BASIC that is called twice from 2 different GOTO statements would be an example of procedural programming.  Object Oriented programming is something different.   There are many similarities between OO and Procedural programming; however they represent two completely different approaches to development.  ( OO is supposed to approach the problem as it would in the real world; Procedural is designed to approach the problem from the perspective of the computer ) At 01:01 PM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- -- Jeffry Houser, Web Developer, Writer, Songwriter, Recording Engineer <mailto:jeff@instantcoldfusion.com> -- AIM: Reboog711  | Phone: 1-203-379-0773 -- My Books: <http://www.instantcoldfusion.com> Recording Music: <http://www.fcfstudios.com> Original Energetic Acoustic Rock: <http://www.farcryfly.com>

Reuse in the small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem. Reuse in the large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desiderable. - Robert L. Glass :-))) Massimo

At 12:40 PM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- Can I get an "Amen"! -- Alex

>>There are many similarities between OO and Procedural programming; Well, no wonder, OOP IS also procedural. Procedural is opposed to event programming, or forward chaining like in expert systems; But programming in the 60ies also included procedures AND event programming. Event programming is the most beautiful thing,... when there are events! In an application, client side, in a browser, there ARE events, so Javascript alows events, fine. On the server side, in ColdFusion, where are the events? >>Procedural is designed to approach the problem from the perspective of the computer Well, as long as I'm working on a computer, I have no problem with that ;-) -- _______________________________________ See some cool custom tags here: http://www.contentbox.com/claude/customtags/tagstore.cfm Please send any spam to this address: piegeacon@internetique.com Thanks.

> Event programming is the most beautiful thing,... when there are > events! > In an application, client side, in a browser, there ARE events, so > Javascript alows events, fine. > On the server side, in ColdFusion, where are the events? The events are still created on the client side based on the user's actions (submitting a form, for example) or they can be announced by the CF code on the server (based on the outcome of an event that was initiated by the user, for example).  If your implication was that there are no events, I think you're missing one of the very basic aspects of how this particular framework works. Lest people forget, the "II" in Mach-II isn't just a Roman numeral--it stands for "Implicit Invocation," meaning methods are invoked implicitly based on events that are occuring within the system.  Maybe having an event that gets kicked off by a user clicking a button isn't quite the same thing as the system itself announcing an event, but that's really an issue of how the event gets kicked off, not whether or not an event exists.  They're both still events as far as Mach-II is concerned. - Matt

>>The events are still created on the client side based on the user's actions (submitting a form, for example) or they can be announced by the CF code on the server (based on the outcome of an event that was initiated by the user, for example). These happen on the client side, not on the server! As far as CF is concerned, these are not events. In the HTTP protocol, there are only TWO things happening : 1 an HTTP request from the client to the server. 2 the answer by the server to the client. And by definition, they happen in sequence, this is just pure linear programming. As far as CF is involved between the two, everything is like with an ordinary program, and nothing may happen from the user. The fact that the request may come from a form, a click on a button, a link, an image in a page or a request from Javascript are just parameters to the HTTP request, they do not constitute events. CF does not even know how the action has been initiated. CF is only noticed if the request method is GET or POST, and the only different is where it should look for the parameters. >>based on events that are occuring within the system. Which events ? It is not because you call anything an event that there are events. An event may be a mouse click, a key hit on the keyboard, a timer request. OK, there ARE timout in CF, but they trigger errors handled by CF in the normal program flow, not events the user can handle himself. Theese are not event. Now, if you call the value in an input field an event, then OK, CF is event programming ! ;-)) >>Maybe having an event that gets kicked off by a user clicking a button isn't quite the same thing as the system itself announcing an event, Especially when it happens on the client side, when CF takes care of this "event", it just gets a parameter from an HTTP request, that's all. It doesn't even know if the request was fire from a link in the page, a form, a refressh from Javascript. CF is just invoked from the server, with some arguments, or parameters, just like any other kind of linear program. >>They're both still events as far as Mach-II is concerned. Then Mach-II is just using a terminology "à la mode" to please those who like new words ;-). -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.

> Then Mach-II is just using a terminology "à la mode" to please those > who like new words ;-). Yes, you're absolutely right--its sole purpose is to please people who like buzzwords.  It clearly has no other benefits!  I'll stop using it immediately. ;-) If you don't like it, don't use it, but I still contend that you don't really get what Mach-II is all about.  You think of events in a very limited way, but when I call "announceEvent()" in Mach-II, stuff happens, so argue against that all you want, but events exist within Mach-II and can be used as such. - Matt

"Object-oriented programming is an exceptionally bad idea which could only have originated in California." -- Edsger Dijkstra Doug At 01:47 PM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- I thought Hal Helms invented OOP? ;-)   _____  

At 05:01 PM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more -----   I would never say that OOP is procedural.  They are two different approaches, in essence, to approaching a problem.  I wouldn't say event programming has anything to do with wether you are using OO or Procedural design methods. >Event programming is the most beautiful thing,... when there are events! >In an application, client side, in a browser, there ARE events, so >Javascript alows events, fine. >On the server side, in ColdFusion, where are the events?    They don't exist.  I think that was your point. > >>Procedural is designed to approach the problem from the perspective of > the computer > >Well, as long as I'm working on a computer, I have no problem with that ;-)   I agree.  I cannot explain why anyone would want to apply OO concepts to ColdFusion.  It has traditionally not been an OO language, although these days you can say that it is a hybrid. -- Jeffry Houser, Web Developer, Writer, Songwriter, Recording Engineer <mailto:jeff@instantcoldfusion.com> -- AIM: Reboog711  | Phone: 1-203-379-0773 -- My Books: <http://www.instantcoldfusion.com> Recording Music: <http://www.fcfstudios.com> Original Energetic Acoustic Rock: <http://www.farcryfly.com>

>>I cannot explain why anyone would want to apply OO concepts to ColdFusion. Just because it is "à la mode", just like Oracle is "à la mode" for a database, even to maintain a database about pizza delivery in your area ;-) Or just like using Java -- the main purpose of which is being platform independent -- on a steady platform, preferabily Windows, that one would never change anyway, because it is Microsoft, and Microsoft is "à la mode" ;-)) -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm Please send any spam to this address: piegeacon@internetique.com Thanks.

I think Claude was trying to get the point across that a lot of frameworks tout "code re-use", which is, in my opinion, nothing more than a talking point used to excite people about methodologies in general.  Neophytes wet their pants about this all the time, but for people who know the merits of OOP and have been reusing code before they ever even knew that OOP was an acronym, it would take severe blows by heavy machinery to the kidneys to get the same effect. If you look back at all the legendary Fusebox arguments on this list, a lot of proponents that didn't make their arguments very well would fall back on this statement.  For me, I just love whatever gets the job done for a specific project, no matter what it is. -Andy At 05:01 PM 5/27/2004, you wrote: ----- Excess quoted text cut - see Original Post for more ----- programming.   I would never say that OOP is procedural.  They are two different approaches, in essence, to approaching a problem.  I wouldn't say event programming has anything to do with wether you are using OO or Procedural design methods. >Event programming is the most beautiful thing,... when there are events! >In an application, client side, in a browser, there ARE events, so >Javascript alows events, fine. >On the server side, in ColdFusion, where are the events?    They don't exist.  I think that was your point. > >>Procedural is designed to approach the problem from the perspective of > the computer > >Well, as long as I'm working on a computer, I have no problem with that ;-)   I agree.  I cannot explain why anyone would want to apply OO concepts to ColdFusion.  It has traditionally not been an OO language, although these days you can say that it is a hybrid. -- Jeffry Houser, Web Developer, Writer, Songwriter, Recording Engineer <mailto:jeff@instantcoldfusion.com>

Having watched this thread with interest, I think part of the discussion is kind of running around the issue of what is OOP as whether or not CFMX is OO or not. For me, I tend to think of CFMX as being Object Based rather than Object Oriented much like older versions of Visual Basic were Object Based. Languages like C#, C++, Java and Delphi are fully Object Oriented in that they support inheritance, encapsulation and  polymorphism which are generally regarded as the three pillars of OO. If one of these is missing or has a limited implementation then the language falls short of being truly OO and belongs in the category of being Object Based. The thing is whether its procedural, object based, object oriented or whatever else you can think of, code re-use has been around for a very long time... I remember programming with code libraries 20 years ago on my 8-bit 1MHz home computer with 32Kb of RAM. I was 9 years old and had already learnt the tricks I needed to make my life easier by loading code libraries into memory and then accessing them from my applications using assembly language. 20 years on, to be totally honest, not much has changed. I now have a formal Software Engineering background which began with the first lecture on my first day at University entitiled 'Code re-use... Steal everything'. Now the lecturer was not advocating software theft in anyway but he was advocating the use and re-use of code to the n'th degree. He also pointed out that there could never be a good enough reason to re-invent the wheel, so applying that to software, when there is so much code out there that is freely available, why not use it? Code re-use is and will always be a  very useful tool for software developers. Is the how, when and the where of its first use really that important?????

>>Code re-use is and will always be a  very useful tool for software developers. Is the how, when and the where of its first use really that important????? Well said. For me what's important is using the right tool in the right circumstance, and what it has been designed originally for, not any new thing just because every body talks about it and you don't want to look like you are left behind. Example: BASIC stands for BEGINNERS All-purpose Instruction Code. It was originally designed to be an interpreter (by definition) to simulate a calculator for beginners and for pedagogical purpose only. Microsoft has made a compliler and a language for "professional" our of it, well, why not? ;-)) Example: Java is a virtual machine which uses a real machine to emulate another one which does not exists. Any program runs about 10 times slower than the same compiled in C or other. The BIG advantage however is that the program is machine independant and could be easily migrated to UNIX, Windows, LINUX, and probabilly even on a toaster, fine! But how many people are programming in Java and have absolutely NO intention to migrate to a different machine? Example: Oracle is a very powerful database system, capable of handling terabytes of data, but it is rather expansive, requires "database managers", dedicated servers, etc. But how many companies have Oracle just to maintain the boss agenda and telephone book? ;-)) Some people need a combine-harvester to mow their 100 sq.feet grass, just to make impression on their neighbours ;-) -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.

I don't get it. No matter what list I'm on, sooner or later or every 3 months, someone asks for an opinion on FB (now Mach-II). The detractors are usually the first out of the gate. "I create my own enterprise level frameworks using hand-crafted bits and a time-tested event model I first palyed around with when punch cards were new. Everyone should create their own frameworks because preexisting frameworks have waaaay too much code-bloat and they can't possibly address my situation as well as I can." And the battle rages for a while. Then some gets around to saying, "well, really I'm an advocate for the right tool at the right time." Why don't these people realize that sometime it is more useful to spend time solving problems rather than crafting tools to solve problems. "Because I know I can make a better framework" is not always a good excuse. This is why I use Fusebox for my web application framework, OS X for my development platform, and Linux for my server platform. They work, and I can spend my time solving problems created by my business users and less on creating tools to do so, or workstation administration, or server administration. -- Howard Fore, mylists@hofo.com On May 27, 2004, at 10:34 PM, Claude Schneegans wrote: > For me what's important is using the right tool in the right > circumstance, and what it has been > designed originally for, not any new thing just because every body > talks about it and you don't want to look like you are left behind.

What I object to is your implication that if someone doesn't use an "approved" framework, they are re-inventing the wheel and not trying to solve real-world problems.  The "if you're not with us, you're against us" mentality some Fusecattle hold is just ridiculous.  Just because someone creates their own framework doesn't mean they are "detractors".  Let's face it, just because people didn't follow the path you've taken to acheive development Nirvana doesn't mean they went about it the wrong way.  I don't like a lot of things; does that mean I detract from them? Also, I don't understand how using OS X and Linux cuts down on your administration time.  These things are fallable just like everything else. In my experience, it is skill coupled with patience and the leveraging of specific tools (in some instances) that gets the job done. -Andy I don't get it. No matter what list I'm on, sooner or later or every 3 months, someone asks for an opinion on FB (now Mach-II). The detractors are usually the first out of the gate. "I create my own enterprise level frameworks using hand-crafted bits and a time-tested event model I first palyed around with when punch cards were new. Everyone should create their own frameworks because preexisting frameworks have waaaay too much code-bloat and they can't possibly address my situation as well as I can." And the battle rages for a while. Then some gets around to saying, "well, really I'm an advocate for the right tool at the right time." Why don't these people realize that sometime it is more useful to spend time solving problems rather than crafting tools to solve problems. "Because I know I can make a better framework" is not always a good excuse. This is why I use Fusebox for my web application framework, OS X for my development platform, and Linux for my server platform. They work, and I can spend my time solving problems created by my business users and less on creating tools to do so, or workstation administration, or server administration. -- Howard Fore, mylists@hofo.com On May 27, 2004, at 10:34 PM, Claude Schneegans wrote: > For me what's important is using the right tool in the right > circumstance, and what it has been > designed originally for, not any new thing just because every body > talks about it and you don't want to look like you are left behind.

On May 28, 2004, at 1:10 AM, Andrew Tyrone wrote: > What I object to is your implication that if someone doesn't use an > "approved" framework, they are re-inventing the wheel and not trying to > solve real-world problems. No, no, no. That's not what I'm implying. That may be what you're interpreting, but that's your choice, as it is was Claude's choice to read "OO allows code reuse" as "OO allows code reuse for the first time in the history of mankind." However, by definition if one creates a product that accomplishes the same task as another product, they are reinventing that product. Approval is a different matter entirely. My choices are just that. Mine. They are based on my personal experience and they are thus affected by every project I have worked on and will work on. But those choices are necessarily subjective because they are based on my judgement and standards. Perhaps those people who complain about "code bloat" have tighter standards than I do. Maybe they evaluate the tradeoff of shaving 10 milliseconds from response time versus the 2 hours it may take to reach that point differently. These are personal decisions. There is no Underwriter's Laboratories saying that your application will fail because you wrote your own framework. What I object to is the lack of reasoned answers. Surely these people bright enough to write their own scalable, lightening fast, lean, reusable-to-the-nines frameworks are also bright enough to realize that there are at least two sides to every issue. That few things are truly all black or all white. When someone asks, "Hey, I'm new to frameworks. Should I use FB and/or Mach-II?" it serves little of the collective good to stand up with a flamethrower and blast everything that is not customized for a specific project. ----- Excess quoted text cut - see Original Post for more ----- No, but if all you do is say bad things about the things you don't like then yes, you are detracting from them. "Detractor, noun: one who disparages or belittles the worth of something." > Also, I don't understand how using OS X and Linux cuts down on your > administration time.  These things are fallable just like everything > else. > In my experience, it is skill coupled with patience and the leveraging > of > specific tools (in some instances) that gets the job done. Yes, everything is fallable. My PowerBook locked up hard last night, to the point I had to power cycle it to recover. I'm sure there are Windows users who can sympathize. I'm dissatisfied with almost every method of software delivery and packaging in Linux with the instances of cascading dependencies. Patience is sometimes not my long suite. My experience in computers has shown that more often than not, I get better results quicker by using OS X (and Macintoshes in general) and Linux than attempting the same with Windows. I'm know there are those with exact opposite experiences. I know that leveraging the tools of OS X, FB, and Linux will the most of the jobs done that I encounter. Perhaps if I had more patience I could swallow spending the extra time developing the skills to accomplish the same thing in Windows. I choose not to. That doesn't mean you can't or shouldn't. Somethings are worth specialization, some things aren't. Again, your choice. One size doesn't fit all, whether it is FB, Mach-II, onTap, JSP, Tapestry, or WebObjects. But each has it's good and bad points. It is counterproductive to present subjective, one-sided answers to those looking for an objective view. -- Howard Fore, mylists@hofo.com

>>as it is was Claude's choice to read "OO allows code reuse" as "OO allows code reuse for the first time in the history of mankind." C'mon, please be honest, this is NOT either what I said. But when some one says "OO allows code reuse" it is AT LEAST presented as an advantage, either because it does it better, OR because other solutions don't allow it. What I say, is that in both cases it is just a false statement. -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.

Actually, this is an exact quote of what you said: 'But when everybody says "OOP allows or enables, or whatever, re-using the code", it promotes the idea that no code was re-used before, and THIS is just not true. OPP makes re-using code just a bit more systematic, no more, and good programers will still re-use code just as before, and even with OOP, bad programmers may not.' M Claude Schneegans <schneegans@internetique.com> wrote: >>as it is was Claude's choice to read "OO allows code reuse" as "OO allows code reuse for the first time in the history of mankind." C'mon, please be honest, this is NOT either what I said. But when some one says "OO allows code reuse" it is AT LEAST presented as an advantage, either because it does it better, OR because other solutions don't allow it. What I say, is that in both cases it is just a false statement. -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks. ---------------------------------

My apologies. In my venting I did blow your statement out of proportion. However, "OO allows code reuse" does not say "OO does code reuse better than anything else" or "OO is the only way to accomplish code reuse." The statement merely illustrates a capability of OO. If someone made the second and third statements they would, as you point out, be incorrect. -- Howard Fore, mylists@hofo.com On May 28, 2004, at 1:50 PM, Claude Schneegans wrote: ----- Excess quoted text cut - see Original Post for more -----

>>The statement merely illustrates a capability of OO ... A particularity, otherwise one would not talk of it. If you can do it with any language, which is the case, why mention it ? Do you see advertised "At Hilton Hotels, one can rent rooms for night" ? ;-)) If this is the way people read, no wonder they see events in ColdFusion ;-) Say how about a WYSIWYG CF ? this was à la mode also in some times`;-)) -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon@internetique.com) Thanks.