Thursday, October 20, 2005

Afternoon Fusebox Class Update

So far, it's been rather educational. We're on the same path of wanting long term great applications, but there are some serious thoughts made into fusebox. I still feel it has major work to get to where it will both be more usable and scalable from the end-user perspective.

However also, there is a lot of setup involved as a new fuseboxer to create each application, if that can be simplified or automated that would really help.

However what this class is introducing me to, is the real necessity for frameworks or methodologies in coldfusion...

Jared is damn smart, I may ask a lot of stupid questions, because I want to get a full understand, and having only worked on 1 fusebox application, in terms of incorporating it in an existing non-fusebox application, it can be difficult to grasp.

I find that fusebox can be a great doorway to learning more of frameworks and getting more polish into your professional skill set.

I find that very vital...

Here are my afternoon class notes for my fellow classmates in MCTC. And we had a great lunch at Davanni's oh man that was filling.

------------------------Afternoon Class Notes --------------------------------
Installed CFMX 7
Installed Dreamweaver 8 YUCK!

SkeletalMVC
-Controller - xml files, configuration of all fuse actions????
-Model - CFM Files
-parsed - parses xmls and compiles directives and cfml template and executes
-plugins -fusebox plugins cfm templates, referrenced from the xml file
-view -interface files, form tags, table tags

-Controller Circuit main.prodlist
-Model query select * from tblProds - getallprodsqry.cfm
-View -/include dsp_prodlist.cfm Include layout.main.cfm name=body

layout.cfm looks like this
#body#

Saves whole app to the parsed folder -- Worth investigating

For each fusebox application, you have to reconfigure, drop skeletalMVC folder/files

precedenceFormOrUrl either do form or url grabbing...which takes precedence...
password - force fusebox to reload a file in the parsed folder
mode - development vs production

globalfuseactions
-preprocess
-postprocess

This is the configuration file fusebox.xml.cfm

Each application would get it's own configuration file.

enumerate what does that mean?

structkeyexists(variables,"dateTime")
-a symantic improvement

page contest

scope prioritization, scope variable searching...

page context level for each variable scope



1. Plan it out
2. Create model
3. Create views
4. Create XML behind two

Nifty circuit aliases, to reference functionality in different parts of the application

circuit access="public" vs access="internal"

internal mode is kind of interesting...

circuit.fuseactionname

Fusebox can be fun to play with, I am not sure about it's scalability or index.cfm?fuseaction issue, how it appears the developer does matter, and I am fine with that. If the two main issues are dealt with i am fine.

I am curious about the process of the compiling into parsed files...

Why not have the database do it's parsing of content and then in a stored procedure get the call of what content to display. Point being why not have the database do all the work instead of having coldfusion do it.

Controller gets the request and passes the work on to model then displays results via view.

use fusebox tags rarely unless necessary...

I think it is realistically possible to hide the links that go to the same page, either thru javascript, or we can have a link page creation process...

Where we loop thru each fuseaction and create a physical file for each that actually calls the fuseaction,but how does that deal with form or action pages. Unless it was done via a cfinclude.

2 comments:

  1. Anonymous6:07 PM

    Fusebox compiles the XML description of the control logic down to CFML - it has nothing to do with "content" and nothing to do with a database (and in fact this sort of thing would be completely inappropriate for a database).

    The URLs can easily be replaced by SES style stuff if you want (so http://domain.com/circuit/fuseaction/other/params instead of http://domain.com/index.cfm?fuseaction=circuit.fuseaction&other=params for example). That's all about how you configure your web server etc. For comparison, my site uses index.cfm/fuseaction/circuit.action (and handles the SES translation in CF directly).

    Looks like you learned a lot and seem to appreciate at least some of the benefits of using a standard framework now. Keep practicing the Fusebox stuff and hopefully you'll start to get more interest on the job front.

    ReplyDelete
  2. Now I already knew about the ability to convert url variables to / variables. That is not my concern.

    My concern is the references to index.cfm which all refer to the same page as far as the customer can see.

    A lot of this has ideas and potentials but I don't think we're there yet in terms of understandable and bookmarkable urls for our regular browsers yet...

    We're on our way, a lot to know and learn yet, but this was just my first day.

    ReplyDelete