|
|
MillionMunkeys ->
Products ->
TrafficMunkey™ ->
Here at MillionMunkeys, we've been using frameworks for years, but about a year ago we set out to design our own. Why build yet another framework? Well, each developer tends to use each framework differently. You tend to settle on patterns that work for you. Sometimes the way you want to work isn't supported, or you find that you just never have a need for certain features. Eventually, some developers just start from scratch as an experiment, to see if there is another way that best fits their way of working. Then they put the result out in the wild to see if there are other people like them.
Here are the goals that were driving us to experiment and invent:
- Small Footprint: In the frameworks that I use, there are a lot of features that I do not use, yet in many cases, these features were still loaded and built in-memory, even when I didn't access them during a Session. So one goal I kept in mind was to not load any feature until it was used. The PiComponent is core to this goal.
- Graphic-Design-Friendly: I have a background in Graphic Design and work with Graphic Designers who do not necessarily know how to code. They use WYWIWYG editors and need to be able to see graphics in place, and the entire picture as a whole. But if they change the design, I don't want the editors to kill any of the code.
- Rapid Prototyping: Core to my way of working is prototype-after-prototype, each becoming progressively more complex with each pass.
- Fast Edits: Since I'm constantly editing prototypes based on the clients. I want to make edits only once, whenever possible. For example, with some of the other frameworks, if I changed the nature of a page and changed the filename itself, I then had 2 or 3 linked names to edit as well. For example, a filename might also have a matching handler function name, plus a corresponding URL ID. With enough modifications, this just became tedious. If it also had a corresponding action ID, then I was looking at 6 edits.
- Progressive Complexity: The goal with TrafficMunkey™ is to be able to layer code on top of each other. For example, with TrafficMunkey™ I can build one atomic piece, then wrap it with a template, then progressively add action functionality based on triggers through the PiComponents.
- Global Objects: I like the use of global objects in frameworks, and wanted to preserve these features, while also adding context such that the objects are not created unless, and until, they are used.
- Real URLs (not just Search-Engine-Safe): I've never been happy with URL IDs. I like working with filenames, because the filenames themselves are IDs. Yet I understand the history of the IDs, and prior to CF 7 it just wasn't possible to do it any other way. But now that we have the Application.cfc and we can intercept requests with the OnRequest method, we can use templates, and do global processing, while still maintaining the original filenames.
- Plus Aliases: With CF 8, and the OnError method, we can also now create aliases. In other words, if you move a page to a new location on your site, but other websites are still linked to the old location, you can intercept the old URL and redirect the user to the new URL. With TrafficMunkey™ this is handled all in one place.
- Adobe Dreamweaver Integration:
I get ribbed about this all the time by coders, but with my Graphic Design background, and because I work with designers, at times it's much faster to get yourself out of Code View, and Dreamweaver helps me to do that. None of the other frameworks, though, work with the built-in Dreamweaver features. TrafficMunkey™ does.
- Cohesive HTML: To use Dreamweaver's Design View, you can't have unmatched tags. Each template must be complete set of tags unto itself.
- Images display: Your links also have to be true, relative links so that Dreamweaver can load the needed CSS files and image files, so that you can see them in context. TrafficMunkey™ allows you do this.
- Preview in Browser: Dreamweaver has a great right-click, preview-in-browser shortcut, but you can't use it with other frameworks. Because TrafficMunkey™ goes back to actual filenames, and applies templates through the OnRequest function, this is another convience feature that just works.
- Adobe Contribute-compatible: I have several clients that want to edit their own content, and I want them to. Adobe Contribute can be great for this, but when dealing with global templates, you can't have unmatched tags, plus you have to be careful that the editor won't rewrite the code and screw anything else up. I also don't want them editing the template for only one page, breaking consistency across the site. Cohesive HTML and additive features solve this goal.
- XFAs: I love this feature from Fusebox, and being able to define links between pages, all in one file, so that you can quickly see interdependencies. LinkMunkey™ preserves this concept within TrafficMunkey™.
|

|