fusebox vs model glue

hi we have just reviewed model glue, and have also looked into fusebox very briefly is fusebox similiar to model glue? and if so is it a case of using one or the other? and if so then what are your feelings on which one is better? thanks for your help richard

----- Excess quoted text cut - see Original Post for more ----- wow.  this should be interesting :) which one is "better" is going to be highly *highly* subjective.  the first framework that I learned was Fusebox (4.1).  it did make learning Model-Glue easier, as there are a number of similarities, and I could take MG concepts and think of it as, "oh... this would be _______ in fusebox". personally, i'm a huge proponent of the concept of frameworks (whether it's a community-supported one or your own home-grown).  they help standardize your development, promote a consistent way of coding, and if done right, do make smaller bits of reusable code.  so IMHO, there's no "wrong" answer to which is "better".  whichever framework you choose, if implemented properly, will give you these benefits. that being said, your best bet as to determining which one is "better" (for you) would be to build small sample apps with both, and see which one feels better for you. -- A byte walks into a bar and orders a pint. Bartender asks him "What's wrong?" Byte says "Parity error." Bartender nods and says "Yeah, I thought you looked a bit off."

> Richard White said: > is fusebox similiar to model glue? and if so is it a case of using > one or the other? and if so then what are your feelings on which one > is better? Although it might not mean much right now, I'll say very briefly that Model-Glue is an OO framework, meaning that, if you're not using OO now, you WILL use OO if you start using MG, because the framework doesn't give you a choice in the matter. That's not intended to be derogatory, some people consider this a benefit. Fusebox on the other hand offers a variety of different ways to develop your application that can actually be used interchangeably. So one circuit may be designed in an OO manner while others are designed in a procedural manner. That's also not necessarily an endorsement of Fusebox either. Some people consider this a drawback. :) > Charlie (Good) Griefer said: > that being said, your best bet as to determining which one is "better" > (for you) would be to build small sample apps with both, and see which > one feels better for you. This is an answer that a lot of folks give when the question of "best framework" crops up. (In addition of course to the variety of people who answer to say "Fusebox" or "ColdBox" or "FarCry".) A while back Brian Rinaldi had this comment about that approach: "Personally, I dislike the advice of building sample apps with each Framework. It is confusing and difficult if you are new to a frameworks and OO and it is time consuming. Therefore completely unrealistic unless you have lots of spare time." Sean Corfield of course always gives the answer "it depends", which if I'm being pragmatic is pretty appropriate. If you've got a group of programmers who're comfortable with a particular style of development, you're liable to lose productivity if you try the "sink or swim" approach with a framework that uses a really different approach. So it makes sense in general to choose a framework that your team is comfortable with. If you're new to frameworks in general though, often the array of available frameworks can be rather intimidating, and a lot of folks end up putting off learning frameworks in general in the hopes that soon the "one true (standard) framework" will come along and be the obvious choice for every project. Although if you find yourself in that position, the thing to remember is this: it won't. That's not a criticism either, it's just human nature to be indecisive for fear of losing options. Here's a blog I wrote about natural indecisiveness with regard to frameworks: http://ontap.riaforge.org/blog/index.cfm/2008/5/2/Indecisive Shortly after that I started working on a project that may interest you in which I ported Ray Camden's Galleon forums to several different frameworks. I chose Model-Glue, Mach-II, ColdBox, 2-flavors of Fusebox and my own onTap framework. The article here shows a comparison of how different common tasks are accomplished with each framework and you can download the archive with all the ports of Galleon if you want to see the actual code used to port them: http://on.tapogee.com/galleonproject/ That should give you a birds-eye view of the different frameworks without having to take the time to redevelop the same application several times, since I've already done that. :) Although it doesn't get into some of the more specific details of the other frameworks, like it won't explain what addResult() is in Model-Glue or why you need it (a very OO concept). Lastly I will say that the other four frameworks are all "front controller" frameworks, so urls like index.cfm?event=yadda.yadda will be common across the board. The onTap framework on the other hand is a "rear controller" framework, and while it will *allow* urls like that, it's designed to offer the flexibility to allow you to write URLs however you prefer. As a matter of fact, pages can be easily moved into or out of the framework without changing their URL at all and without the person visiting your site needing to know that you're even using any kind of framework. There's an article about the "rear controller" design pattern on the framework wiki here: http://ontap.wikispaces.com/The+Rear+Controller+and+You Good luck in your selection process :) ike -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 781.769.0723 http://onTap.riaforge.org/blog

I may be in the minority here, but I've come into several projects that use Model Glue AND fusebox (turning it into a confusing mess for us developers who don't know much OO programing). If you do happen to pick a framework, if possible, please try to stick to that one. :)

> I may be in the minority here, but I've come into several projects that > use Model Glue AND fusebox (turning it into a confusing mess for us > developers who don't know much OO programing). > > If you do happen to pick a framework, if possible, please try to stick > to that one. :) I would expect that to be fairly confusing. :P -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 781.769.0723 http://onTap.riaforge.org/blog

Oh... Beyond belief. :) I could try to explain HOW confusing... but I can't even begin to explain it. That's how confusing it is. :) But the last 5 contracts I did (with different people) had Model Glue with a "fusebox like" setup (or standard fusebox). Hopefully, I'm just unlucky and this isn't a trend. s. isaac dealey wrote: > I would expect that to be fairly confusing. :P

Hey Ike: Hell of a well-thought out post.  I was going to snip it down and keep only relevant bits, but it was all pretty relevant (so um yeah... i snipped it all) :) the one point i'd like to try and make in response is that, yes... learning a single framework can be daunting and/or intimidating... so suggesting "learn them all and pick the one that feels right" might seem like bad advice (or, at the very least, less good advice).  but here's the thing... i think once you grok the basics of one, learning others won't be *nearly* as daunting or intimidating.  as i had alluded to... the fact that i had somewhat of a grasp of fusebox definitely helped me in picking up model-glue.  that's not to say they're "interchangeable", but it's definitely easier to learn your 2nd framework than your first.  i've recently started to play around with ColdBox and again... understanding the concepts behind a front-controller MVC framework has made it much easier. so, with all due respect to both you and Brian... i'd still stick with that response.  yes, it *is* confusing and difficult if you are new to a frameworks and OO.  but you're only new to frameworks (maybe less the OO piece) the first time :)  after that it's more "hmm... i'm used to doing it -this way- in "framework x"... i see that "framework y" does it like -this-. obviously, there's still learning to do.  and everyone's time is at a premium.  i'm not suggesting building something along the lines of a full-blown CMS application with each framework.  for my foray into ColdBox, i took a page from Dan Wilson's book and did a simple contact manager. the investment of time, and the frustration of trying to grasp something new... that's all part of learning.  it's not always fun, but i've generally found it to be well worth the pain when the light bulb does finally go off :) -- A byte walks into a bar and orders a pint. Bartender asks him "What's wrong?" Byte says "Parity error." Bartender nods and says "Yeah, I thought you looked a bit off."

> Hell of a well-thought out post.  I was going to snip it down and > keep only relevant bits, but it was all pretty relevant (so um yeah... > i snipped it all) :) <PeppermintPatty>   Thanks Chuck! </PeppermintPatty> Actually I do appreciate the complement. :) ----- Excess quoted text cut - see Original Post for more ----- I will actually nod general agreement to everything you've said here. :) Though I will also say that as an individual developer and having already had a good deal of experience with Fusebox 3 and 4 it still took me a good 2 weeks or maybe a little more of solid work to get those Galleon Ports done and the Model-Glue and Mach-II versions weren't quite finished. A few things to note about that 1) I did take a day out to swap Ray's cfqueries for my own ORM, which I did not do for any of the other frameworks (ColdBox, Fusebox, etc.) because none of them had built-in ORMs. (I didn't do FarCry, sorry. Didn't occur to me at the time, though it does have a built-in ORM called FourQ.) 2) I'm not sure if most developers would have put the kind of time I put into that. That's not intended as any kind of disrespect to other developers... Sean Corfield may be a notable exception, since I know he's done similar things in the past... but I really wouldn't expect most programmers to have the kind of lack of sleep or social life that I usually have (largely due to autism). In the end I think I might prefer not to be autistic and have a social life, but that's not the set of cards I've been dealt. 3) I personally consider Galleon to be a pretty small application... I'm not sure if it qualifies as being as small as the theoretical contact manager, but that's my take on it anyway. There are only about 4 or 5 tables in the database - users, conferences, forums, threads and messages. So I'm not sure how that compares to the contact manager for size. All that being said, even though the Model-Glue and Mach-II ports were never really completed, the purpose really was to show that knowledge of frameworks does transfer from one to the next like you said, so that having a general understanding of frameworks is ultimately more important than which framework you choose to start with. And moreover that learning any framework will help give you that general understanding. The article merely gives you a way to read through the side-by-side comparisons to help you get a generalized understanding up-front without necessarily having to start by building something in each framework yourself. More like a primer. Once you've read it, that should help make the transition a bit smoother. And yes I do promote my own framework a lot in the article. :) -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 781.769.0723 http://onTap.riaforge.org/blog

> hi > > we have just reviewed model glue, and have also looked into fusebox > very briefly It might be good to also review Coldbox. www.coldboxframework.com Will

Disclaimer: I just took over the Fusebox core files so my opinion is most likely slaned ;) Well the easy answer here is no they are not similar and yes use one or the other. The hard answer is that evil last one. What's the maturity level of you/your group? Fusebox offers a vast bit more flexibility in how you code (not forcing you into an OO, or pseudo OO approach) if you think you are just doing CRUD applications most of the time you will most likely end up with a Procedural Object Oriented Program (yep thats right you end up with POOP) if you use MG. Thats not to say poop in this regard is always a bad thing just know what you are heading for and accept that you will pay the OO hit for all your applications regardless of the nessecity for OO. This is one on of the reason I sort of like fusebox it can be made to compliment different levels of applications. You have an application that is very behaviour driven with a rich domain model? No problem model it out and use Fusebox as a nice front end controller. You have a reporting app that is chock full of complex queries but not much more? No problem write out your queries in a coule of qry_ files and display them with some layouts and dsp_ pages. Why take the OO hit for a reporting app? Fusebox is not the silver bullet mind you, but it has not failed me yet in an enterprise with more than 20 apps written in fusebox ranging from internal workflow apps to enterprise level CMS apps. Adam ----- Excess quoted text cut - see Original Post for more -----

Sounds like with FB you could end up with a Pretty Entertaining Environment. Is there a down side to all the flexibility?  :-) -- The community of masses of human beings has produced an order of life in regulated channels which connects individuals in a technically functioning organisation, but not inwardly from the historicity of their souls. Karl Jaspers ----- Excess quoted text cut - see Original Post for more -----

denstar wrote: > Sounds like with FB you could end up with a Pretty Entertaining Environment. *groans* > Is there a down side to all the flexibility?  :-) Yes. It means that no 2 application developers will develop websites the same way. Though IMHO, that's not much of a downside.

Hell yes there can be a downside to flexibility. That's one of the things I've always complain about with fusebox, but I am not planning on changing that flexibility. With a good set of best practices and coding standards you can wrangle in the variations some and not loose all your flexibility, unless you make a stupid standards that are too rigid like you must always use CFCs. You can further alleviate unneeded variance with code reviews and good design principles. Adam! On Sun, Aug 31, 2008 at 2:58 PM, Phillip M. Vector < Vector@mostdeadlygame.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> Hell yes there can be a downside to flexibility. That's one of the > things I've always complain about with fusebox, but I am not planning > on changing that flexibility. With a good set of best practices and > coding standards you can wrangle in the variations some and not loose > all your flexibility, unless you make a stupid standards that are too > rigid like you must always use CFCs. You can further alleviate > unneeded variance with code reviews and good design principles. I tend to agree with Adam's assessment. I've attempted to create an environment with the onTap framework which offers that similar flexibility to start out with quick procedural coding and then quickly and easily refactor it as needed into an OO/SOA approach. What I'm really working on mostly in the past month or two has been to grow the community more than anything else. I am still working on code, but it's not all for things I'll be using myself. Right now I'm working on something I always said I never cared for -- a code generator. Specifically a scaffolding tool I'm calling FireLadder. I probably won't use it for my own applications, however, I know that a lot of folks are interested in having it and so that's why I'm working to provide one. And while the scaffold tool will create cleanly separated models, views and controllers and hook them into the framework's IoC Manager (part of it's overall SOA design), the tool itself isn't quite that sophisticated because it really doesn't need to be, and because an application in production doesn't need the extra load of having a scaffolding tool loaded up into its SOA config since it should never be used by your clients or visitors. At least to me, it makes more sense for a "one time" building tool like this to simply build the infrastructure and then get out of your way. And I'm always excited to get more feedback at http://on.tapogee.com -- or on the new wiki or google group. We even added blog-style comments to the entire framework site. So the home page and every page of the documentation now has comments at the bottom to help us tweak them and make them better. :) -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 781.769.0723 http://onTap.riaforge.org/blog

> denstar wrote: >> Sounds like with FB you could end up with a Pretty Entertaining Environment. > > *groans* First I was going to go with Pretty Incredible, Sophisticated and Simple-- but thought that it was a little much.  =] >> Is there a down side to all the flexibility?  :-) > > Yes. It means that no 2 application developers will develop websites the > same way. Though IMHO, that's not much of a downside. I was just having a gas, I wasn't really implying that X framework forces one to be organized. It's just as easy to Create Rockingly Applicable Performant code with any framework, I reckon. The key, IMO, is getting the concepts, more than the FWs themselves. FWs can help, but it takes real thinking, in the end, no matter what (well, I guess.  Maybe there will be a point in time where I'm like "yes, this goes here, and that goes there!", and not have any question about where X should go... but I doubt it.  I don't, (from years of watching) think that it works that way)). Hmmm, so long as we're talking acronyms, what about some TDD, folks? Hey, Isaac, you got unit tests being generated as well?  I'd toss that in there, while you're at generating stuff. I'm loving my tests... But screw writing all that STUFF by hand. -- The history of philosophy is not, like the history of the sciences, to be studied with the intellect alone. That which is receptive in us and that which impinges upon us from history is the reality of man's being, unfolding itself in thought. Karl Jaspers

> Hey, Isaac, you got unit tests being generated as well?  I'd toss that > in there, while you're at generating stuff. > I'm loving my tests... TDD is on my ever growing list of things to tackle. :) Not something I'm doing currently, but it is something I plan to do at some point. As of yet I haven't been hit by any maintenance steamrollers tho... I'm generally able to switch tracks pretty quickly... For example, prior to this latest version (3.2) of the onTap framework and for as far back as I can remember, the bulk of the code in a framework application has been inside a /_components/ directory. In version 3.2 I made a sudden decision to change the name of that directory to /_tap/ ... I realize a lot of folks might say "wha?! what for?", but I was looking at it one day and some comments I had made about being surprised by some variable names in Galleon that weren't very specific (i.e. could result in namespace conflicts), and realizing that /_components/ might be somewhat confusing and perhaps a little less likely also be a directory someone else already had in their web root. And it occurred to me that /_tap/ might be a bit more specific, less confusing, etc. So I decided to make the change... A few days or maybe a week later (also amidst a 9-5 job) I think I had completely weeded out all references to /_components/. Now it's possible that I was able to do it that quickly because I really don't have a life and mostly spend my spare time sitting in front of this machine working on software. :P Though I like to think that the reason why I was able to make such a sweeping change so easily is really because although I know it has its faults (like any software system does) by and large the framework has never been a "big ball of mud". So I'm able to make "big" changes like that quickly becuase everything is so well encapsulated. It helps make maintenance and debugging easier. Hopefully it will also help when I start getting into TDD. Speaking of the big ball of mud I actually did sit down the other day and read through the entire article written by Brian Foote and Joseph Yoder. It's an interesting read and while it's not all entirely practical (at least not right away), I think there's some good wisdom to keep in mind in there. Full article at http://www.laputan.org/mud/ -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 781.769.0723 http://onTap.riaforge.org/blog

... > TDD is on my ever growing list of things to tackle. :) Not something I'm > doing currently, but it is something I plan to do at some point. It's cool, really, to have the computer do stuff it can do, while you're doing other stuff, so to speak.  I like the idea of self-tests, actually, but I'm not quite "there" yet. > Hopefully it will also help when I start getting into TDD. Maintaining the tests is what's hard for me.  I don't do it right, so I have to update them, instead of the other way around. I'm sure if you've got some structure going there, writing tests and whatnot will not be too hard. It's actually switching over, to where the tests come first, that's the hard part, for me.  Due to a lot of the reasons listed in that article about big balls of mud.  :] I might never do it, and just move to a higher level modeling language, and then just generate tests for stuff.  Naw, I guess I've already sorta started using tests to flesh things out.  I can't tell you how impressed I am with packages that have huge test suites... but I love watching stuff do other stuff, sorta.  Those green or red marks churning by are titillating. Gives you a sense of confidence (false, of course, and moreso with poorly written tests, but still pretty swell ;] ). > Speaking of the big ball of mud I actually did sit down the other day > and read through the entire article written by Brian Foote and Joseph > Yoder. It's an interesting read and while it's not all entirely > practical (at least not right away), I think there's some good wisdom to > keep in mind in there. > > Full article at http://www.laputan.org/mud/ It's a fun one.  Every time I come across it I read some/most of it again.  Nice to see the problems laid out simply, with some, as you said, good ideas for handling them.  Thanks for the link. I'm sorta thinking that there should be some ways to automate a lot of test creation.  Or a way of flipping the problem on it's head... something like introspection combined with a metasploit sorta deal... hmm... sometimes the things I come up with are just pie in the sky (or, not well thought out, conversely), so I feel bad writing tests and stuff before I know the idea will work, but I should stop that. Freaking throwaway code!  But hey, maybe I'm just planning on tossing at least the first version of everything.  =] Well, this is getting well off the framework versus path.  Although, this is exactly the stuff frameworks are on about, ain't it? Sorta. Heh. Apologies anyways, folks.  |-} -- The key to wisdom is this - constant and frequent questioning, for by doubting we are led to question and by questioning we arrive at the truth. Peter Abelard

----- Excess quoted text cut - see Original Post for more ----- It could also mean that you end up with it going down the TOtally Ineffective Ludicrous Entertaining Technology or TOILET. ok its been a long weekend.

...Which I have run into with MG...most of what we are doing is made overly complex by using MG, which in turns made it overly difficult to debug when we had probs.  I can see where MG would be very useful for a very complex application...but I don't think it is the solution for everyone.  I personally prefer the ease of use and flow of FB (or more specifically, my bastardized version of FB ;-) which based on a combination of my personal coding style that is very close to a fusebox-esque style and a version that we were forced to use due to <emp>draconian</emp> server restrictions at AT&T ). Eric /*-----Original Message----- /* /*Sent: Monday, September 01, 2008 11:01 AM /*To: CF-Talk /*Subject: Re: fusebox vs model glue /* /*>denstar wrote: /*>> Sounds like with FB you could end up with a Pretty Entertaining /*Environment. /*> /*>*groans* /*> /*>> Is there a down side to all the flexibility?  :-) /*> /*>Yes. It means that no 2 application developers will develop websites the /*>same way. Though IMHO, that's not much of a downside. /* /*It could also mean that you end up with it going down the TOtally /*Ineffective Ludicrous Entertaining Technology or TOILET. /* /*ok its been a long weekend. /* /*

Eric sometime we should talk about these draconian restrictions and what you've had to do with Fusebox, drop me a line sometime. Adam On Mon, Sep 1, 2008 at 4:59 PM, Eric Roberts < owner@threeravensconsulting.com> wrote: ----- Excess quoted text cut - see Original Post for more -----

> Eric sometime we should talk about these draconian restrictions and > what you've had to do with Fusebox, drop me a line sometime. I imagine you were thinking something like I was... What was it in Fusebox (of all things) that would be anathema to the server managers at AT&T? FB's always struck me as being pretty non-invasive from the standpoint of server requirements, irrespective of the fact that it's generally not my tool of choice. -- s. isaac dealey  ^  new epoch isn't it time for a change?      ph: 781.769.0723 http://onTap.riaforge.org/blog

They all have their ups and downs, I would imagine. I can vouch for the fact that well-written MG apps, as I assume is the same for the other frameworks, are pretty easy to debug and whatnot. Poorly written, however, sucks donkey balls.  And I've written some code that deserves to be flushed.  I'd love to see it do that little circle... well, guess it's more of a spiral... :-) Seems like that's just how it goes.  A lot depends on your background, strengths, weakness, etc., as to which you'd be able to get up to speed with faster.  And there are some cool choices out there.  It ain't just FB and MG, and yes, it all takes time, but ideas can be worth, like, millions-- and everyone seems to say that trying new things gives them "new" ideas. I know, I know... time is money, and there is a bottom line, and that cold hard logic we all must at least pay some sort of tribute to... But there's more to it than just the... machine mentality, or whatever.  Time is funky-- sometimes a little investment frees up more than you'd think, later on...  whatever you choose to invest in.. or maybe it's sorta like art, and some kinds are more appealing, just cause. Eh, I'm not really sure where I'm going with this.  Heh.  It can all be crap, and it can all be roses, and somehow there's a relation? Bah.  :-) :D -- There is no such thing as a 'self-made' man. We are made up of thousands of others. George Matthew Adams ----- Excess quoted text cut - see Original Post for more -----

hi, apologies for the delayed thanks! - but thanks very much there are some excellent points here and really made me understand. seeing as we are doing everything to understand OO and change our applications into OO it sounds like we should stick with it - it is really helping us understand it further thanks again for your comments ----- Excess quoted text cut - see Original Post for more -----