Monday, October 24, 2005

The Importance of Architecture

Now having completed a really good class on the Intro to Fusebox as taught by Jared, at the MCTC in downtown minneapolis...

I hear that a few of my previous readers and comments expect to be go all google eyes and say how wrong I was and all that.

Well in a sense I was wrong. I really see the importance of having a common architecture to speed up development and the working with teams or individually.

And I also see how usefull it can be to seperate the presentation layer, I can dig it's usefullness. But to me that really depends if you code alone or not.

I still have a lot to learn about Fusebox, I find parts of it fascinating, but other parts not so impressive.

This is not a knock on architecture's, fusebox is obviously a step in the right direction, as great as procedural programming style is, it doesn't really comprehed the long term approach that well. But neither can our focus on architecture get in the way of completing tasks.

I see it as a need of balance, to find the approach that covers the butt in both directions...

1. I really still hate how all the apps refer back to index.cfm I am sure the url variables can be made search-engine compliant, but I am more honestly concerned about the lack of bookmarkability, to help customers know what page they are at.

I understand why all actions go to the same page, because it has a lot of processing to do, to enable all the custom architecture that fusebox has, and any additional methodologies it want's to have working with in, such as Model View Controller. MVC, is kind of cool to be honest.

But i believe that if we can hide what page we are by creating physical pages for each public fuseactions, that calls the appropriate fuseaction with a few lines of code, which will do alot to make the fusebox pages much more user friendly. Easier to remember, and bookmark.

2. Fusebox can be a real bitch to work with if all your other applications are done without a specific architecture or methodology. It really does make it harder to figure out without having worked within fusebox, to translate fusebox apps to non-fusebox methodology.

3. The setup for each fusebox has to be improved and simplified, let's enjoy the architecture without having to each of us create lots of folders, subfolders etc... I honestly found the setup part hard to do, and I can't imagine having to re-create the whole fusebox for each seperate app that exists for the same website. Unless I am missing something, which is possible, after all it was only 2 days of class.

Now for things I am knock down impressed by:

1. I really enjoy working with a solid architecture, it has all teh core values I've always wanted, documentation, coding style, naming conventions, teamwork, workflow, and I want to do a lot more proto-typing, and really get into smoother projects.

2. I kind of am hooked into MVC, still have a lot more to learn and I want to play with it more...

3. I like the idea of a parser of fusebox apps into a much more optimized app, makes complete sense. I am kind of curious to how that exactly works...

4. I want to learn and master FLiP, project management has always been something I am interested in, because it makes development that much smoother. I may be interested in getting certified in Project Management. So I need to find some good places to learn and master Project Management.

Is fusebox perfect? Of course not, no architecture is. But it's a step on the road of evolution of web development/software engineering.

Thank you, and I hope to hear any thoughts you have.


  1. Anonymous4:07 PM

    "... but I am more honestly concerned about the lack of bookmarkability, to help customers know what page they are at. "

    I'm pretty sure that

    will work in all modern bookmarks or favorites...

  2. Anonymous4:58 PM

    Can I make a suggestion..?

    You should change the name of your blog to "Murdered Colloquialisms".

    Its "Goo-Goo Eyes" not "Google Eyes"..!

    Although perhaps you meant to coin a new colloquialism..?

  3. I am sure it does work as a bookmark, in terms of having the end user easy to identify what page they are at, it does help to have seperate application file names.

    Which i believe could be done within fusebox with a few tweaks...

    Because doesn't it seem easier to read

    rather than

    I am not saying don't use fusebox, but it should be disguised from the web visitors.

    Make any sense?

  4. Anonymous5:21 PM

    Glad you enjoyed the course and got a lot of benefit out of it.

    As for the URLs, it's trivial to use SES URLS via web server rewrites and something like:

    would satisfy your bookmarkability criteria. This is always going to be something *outside* any framework since web server URL mapping is a very subjective thing.

    Not quite sure what you mean about the setup issues. You install Fusebox once on your server - all apps share that same core file install. You have a skeleton for each app (but, hey, each app is going to have Application.cfm, index.cfm and a bunch of files and directories regardless of the framework, right?). You add fuseactions to circuits as necessary as you build views and model actions and you add a one line circuit description to fusebox.xml for each circuit. That's pretty minimal.

  5. Anonymous6:27 PM

    Hey Anonymous,

    You might not be correct about the Google eyes reference.

    Though it's doubtful that Craig is old enough to remember the song Barney Google from the fifties which talks about goo - goo googlie eyes.

    In fact it was actually part of the East Lansing, MI school music curriculum.

    Now I am not saying that's where Larry Page (an EL native) got the name but it is one of those things as Arsenio Hall used to say makes you go hmmmm.

  6. Anonymous6:33 PM

    Craig wrote:

    "in terms of having the end user easy to identify what page they are at, it does help to have seperate application file names."

    Craig, I agree it's nice if your application is a ten page brochure ware site and yo have the luxury, but what are you gong to do for complex applications that contain literally thousands and thousands of content pages, which increase in number continually? How on earth are you going to find a mechanism to give each page a unique, "easy to remember" name? Sooner or later your requests are going to start to resemble method calls, each with a unique page ID passed in as an argument.

    As for bookmarking, just make sure that you have provided each of your application's thousands of pages with a meaningful and unique page title. Stick a variable within the HTML title tag, get the page title at the start of each request, etc. etc. Not rocket science (although I never cease to be amazed at how many hand-built and content-managed sites fail to do this)! Of course, you will need a CMS to enable users to manage such page properties, but hey, that's what we're here for right?

    Users have become pretty desensitized to long, cryptic URLs IMO. I wouldn't lose too much sleep over it. Besides, if it's really a problem, it probably means you're working on a serious web application in which case easy-to-read URLs are probably going to be be technically unfeasible, particularly for the "deep" pages.

  7. I think it can be done, i have not started the process of trying to do so...

    But i think it could be automated...

    Have a scheduled task go thru your list of fuseactions that are url-able and create .cfm pages with the fuseaction names, that just call the appropriate fuseaction...

    I am sure it's doable...

    Maybe it was that we did our fusebox ala mvc, and there was more to it's setup.

    As I honestly admit there is still a lot regarding fusebox that i have to learn...

    And btw I am still looking for a job...

  8. Anonymous9:01 AM

    Craig wrote:

    "Have a scheduled task go thru your list of fuseactions that are url-able and create .cfm pages with the fuseaction names, that just call the appropriate fuseaction..."

    You won't need a scheduled task (you like the scheduler don't you? ;)) as fuseactions are not created dynamically by users, but by the application architect, and so any such process could/should be done at design-time.

    Remember that there's a difference between fuseactions that represent a single page, e.g. main.aboutus
    and those that are used to create multiple, possibly thousands of dynamic pages, e.g. fa=article.display&pid=123

    It wouldn't work anyway for the latter kind of fuseaction, as you would have no unique "name" to use, unless you used the unique ID to create a name, as some large sites do (although this would hardly meet) your criteria for being "easy to remember".

    You could ask the users, using the CMS, to choose a name to use for each unique page (you would of course need restrictions on punctuation, character length, a check for uniqueness, etc), but this would add to the number of steps the user is required to take to publish a page and throws up issues of appropriate naming. What if a user misspelled a name used as a page name, it could look pretty silly, e.g. summerExhibishun.cfm, wearToFindUs.cfm, etc :D

  9. I am a big believer in automation of tasks. Why waste my time doing things that I can create programs to do for me.

    Like for example one of my favorite coding tricks, is to create a coldfusion page that will make all the cfparam's for me.

    It's kind of fun, here's the basic trick....

    You first create a list of variablenames like this.

    cfset varlist="fname,lname,address"

    then you loop thru them

    cfloop list="#varlist#" index=x delimiters=","

    then use html entities to create each line fo a cfparam you'll need.

    >cfparam name="local_#x#" default=""<br br

    end loop

    then you run the page, copy and paste all the cfparams into a new application, that you created all the cfparam's for.

    What kind of favorite tricks do you have?