Blog

Luis Majano

October 15, 2008

Spread the word


Share your thoughts

I think that a standard is arising on the way a method is injected with a request bus. My naming was requestContext and I believe mach-ii and fusebox use both event. I think it would be benefitial for developers for me to change this to event. What are your thoughts on this? This would help if a developer wants to switch from one framework to another or doing a transition, if some of the similar elements shared in an MVC framework can remain the same. I am for changing it to event, but I would like to know you opinions?

Add Your Comment

(5)

Feb 27, 2007 14:48:06 UTC

by Sana

Hi Luis,

This makes perfect sense, should have some compatibility to other frameworks, at-least vocabulary should be same, so new developers adopt more easily.

Feb 27, 2007 16:20:13 UTC

by Sami Hoda

Can this be a customizable parameter instead?

Feb 27, 2007 18:07:03 UTC

by Luis Majano

I have been going over this and I think the best way is to just call the method and pass the argument. It would then be up to the developer to name the argument. However, the type of the argument will always be: coldbox.system.beans.requestContext

How does this sound?

Feb 27, 2007 19:09:58 UTC

by Sami Hoda

I suppose that works. Whenever there is a chance for flexibility, I'm for it.

Mar 05, 2007 19:19:15 UTC

by tony petruzzi

Actually most of the other frameworks let you change the name to whatever you want, they just use event as the default. But you are correct when saying that this would make it alot easier to transition from one framework to another.

BTW great work. ColdBox is getting more and more attention lately. I haven't heard anything coming out of the Model-Glue camp.

Recent Entries

bx-toml : Native TOML Support for BoxLang

bx-toml : Native TOML Support for BoxLang

TOML has quietly become the configuration format of the modern toolchain. Rust ships Cargo.toml, Python ships pyproject.toml, and a growing pile of CLIs, deployment platforms, and infrastructure tools expect it. If your BoxLang application needs to read one of those files, or generate one, you now have first class support for it.

Luis Majano
Luis Majano
August 04, 2026
BoxLang 1.16.0 Released!

BoxLang 1.16.0 Released!

BoxLang 1.16.0 is here, closing 50 issues across new features, improvements, and bug fixes. The theme running through this release is control: control over how HTTP clients are created and reused, control over what happens when a request fails, control over how much data a response is allowed to buffer, control over when Java classpaths reload, and tighter alignment with CFML behavior in the edge cases that only show up in production.

Luis Majano
Luis Majano
August 04, 2026
Ortus & BoxLang July Recap 2026

Ortus & BoxLang July Recap 2026

July continued to showcase the rapid evolution of the Ortus ecosystem with major BoxLang releases, innovative developer tools, and expanded AI capabilities. From new runtime features and cloud-native integrations to practical learning resources and technical deep dives, this month's highlights reflect Ortus' commitment to building modern, high-performance solutions for the JVM.

The month also featured community initiatives, conference resources, and international events, including CFCa...

Victor Campos
Victor Campos
July 31, 2026